Possible Ways to Crack the Bootloader

[cush2push]

my thought in it would be to look in the gb ota for the keys and most likely it would have to be one of the first things loaded or checked by the bootloader

Well, based off of what I know so far, that wouldn't work because even if you located the keys, they'd be encrypted.

Id imagine that motorola probably keeps the keys in a safe bolted to the floor with cameras and motion sensors in all directions or something. Is that how it works?

Sent from my DROID2 using DroidForums

i would say sometimes the best place to hide is right out in the open

 

[random190user44]

my thought in it would be to look in the gb ota for the keys and most likely it would have to be one of the first things loaded or checked by the bootloader

Well, based off of what I know so far, that wouldn't work because even if you located the keys, they'd be encrypted.

Id imagine that motorola probably keeps the keys in a safe bolted to the floor with cameras and motion sensors in all directions or something. Is that how it works?

Sent from my DROID2 using DroidForums

i would say sometimes the best place to hide is right out in the open

Are you responding to the first paragraph or my second paragraph? It can apply to either, or both

Sent from my DROID2 using DroidForums

 

[cush2push]

Well, based off of what I know so far, that wouldn't work because even if you located the keys, they'd be encrypted.

Id imagine that motorola probably keeps the keys in a safe bolted to the floor with cameras and motion sensors in all directions or something. Is that how it works?

Sent from my DROID2 using DroidForums

i would say sometimes the best place to hide is right out in the open

Are you responding to the first paragraph or my second paragraph? It can apply to either, or both

Sent from my DROID2 using DroidForums

both actually we have no clue what we are looking for but im betting on its out in the open say if i had a table full of colored balls cups and plates and you need only one of them to open the gate and im not gonna tell you which one it is i have successfully encrypted the key you need to unlock by hiding it out in the open but once you figure out which section to look in the key is made visible if somebody has the log from a the gb official moto ota i would love to look at it im freaking sweet at puzzles

 

[plslowmo]

Yes, impossible.

Sent from my Droid using Tapatalk

Not impossible.... Just very very very very very unlikely.... There are almost literally infinite possibilities it could be.

If there are literally infinite possibilities then the odds of finding the solution are infinitesimally small. And yes, it is impossible, given today's technology to try to crack a 2048 bit encryption.

let's put this in perspective. 2048 bit encryption is not exclusive to android. it's been around for a while. android devs are not the only ones trying to crack it. there are people far more capable who have tried and failed. governments and private companies employ ethical hackers whose very job it is to find weaknesses/crack things like this. like i've always said, it's not going to be basement devs who figure out something like this...its not meant to be harsh its just a reality check...

i do agree that if you dont try itll definitely never happen, but trying something like this is akin to trying to flap your arms and fly.

i think in everyone's excitement to find a solution, they're forgetting just how secure such encryption is. trust me, it's not your mom and pop encryption where you can just do a USB sniff and find the key and then update.zip your way to Custom ROMs. The people who are trying to crack the bootloader are, honestly, just setting the community back because they're wasting time that could be spent on something that's more realistic.

There's only two ways this will happen: Someone at Moto leaks the keys (highly unlikely because of the legal consequences that that person will face if he does it), or someone figures a workaround to bypass the bootloader (which i guess people are trying and is the only "viable" solution, although that is also highly unlikely). Trying to actually discover keys and crack the bootloader is impossible. No matter how much you guys want to believe its not...

I wouldnt say I'm setting the community back lol, I don't have anything real to contribute anyways. The real devs have always been working on more relevant projects. I personally find it intriguing, I dont expect to find anything but a better understanding of the phone.

Sent from my DROIDX using DroidForums

 

[czerdrill]

Not impossible.... Just very very very very very unlikely.... There are almost literally infinite possibilities it could be.

If there are literally infinite possibilities then the odds of finding the solution are infinitesimally small. And yes, it is impossible, given today's technology to try to crack a 2048 bit encryption.

let's put this in perspective. 2048 bit encryption is not exclusive to android. it's been around for a while. android devs are not the only ones trying to crack it. there are people far more capable who have tried and failed. governments and private companies employ ethical hackers whose very job it is to find weaknesses/crack things like this. like i've always said, it's not going to be basement devs who figure out something like this...its not meant to be harsh its just a reality check...

i do agree that if you dont try itll definitely never happen, but trying something like this is akin to trying to flap your arms and fly.

i think in everyone's excitement to find a solution, they're forgetting just how secure such encryption is. trust me, it's not your mom and pop encryption where you can just do a USB sniff and find the key and then update.zip your way to Custom ROMs. The people who are trying to crack the bootloader are, honestly, just setting the community back because they're wasting time that could be spent on something that's more realistic.

There's only two ways this will happen: Someone at Moto leaks the keys (highly unlikely because of the legal consequences that that person will face if he does it), or someone figures a workaround to bypass the bootloader (which i guess people are trying and is the only "viable" solution, although that is also highly unlikely). Trying to actually discover keys and crack the bootloader is impossible. No matter how much you guys want to believe its not...

I wouldnt say I'm setting the community back lol, I don't have anything real to contribute anyways. The real devs have always been working on more relevant projects. I personally find it intriguing, I dont expect to find anything but a better understanding of the phone.

Sent from my DROIDX using DroidForums

Maybe I worded that wrong. I meant no disrespect to you. I'm talking about the people/devs who lead other users on and ask for donations for this type of thing. It's not something that you just "discover" while you're tinkering around at home with some files. Like i mentioned, government agencies and companies with access to thousands of computers, and very sophisticated distributed networks, tons of money and far more resources then any of the basement devs have not been able to crack encryption like this, so it's not going to be some android dev who makes ROMs as a hobby that's going to do it.

I think it's a little misleading and wrong to ask for donations for something like this or tell users "we're almost there!" and then ask for more money etc. I'm just being realistic.

You're absolutely right, it is something intriguing, and you will definitely learn a crapload about encryption and cryptography as you read more and try more. At least you're not asking for money for it haha...can't say the same about other devs.

I mean think about it, how many people have donated to devs who have, for lack of a better phrase, done absolutely nothing? I'm just making the community aware, that "cracking" the bootloader is not going to happen. And if it does (which it won't), it's going to go beyond android. It will be an international news story, not just something that sits here on df.net with us celebrating and saiyng "suck it moto!" lol. It's going to be a big deal...a huge deal, and the person who does it (not that it's going to be done, because it won't) will become an insta-celebrity.

But I digress...the reality of it all? Not happening.

And when I said "set the community back", I meant it as a waste of time, if you're truly trying to find a viable solution. If you're just doing it for fun to learn something then by all means, that's your prerogative. But if you're asking for money and telling people "we're almost there", you're just lying to people and misleading them, and yes that is setting the community back. (Again, not referring to you specifically)

 

[WugFresh]

@czerdrill
My original intentions with this approach were actually not aimed at finding the unencrypted keys but rather to direct the focus on determining everything else, as in to identify the normal bulk data regions and attempt to splice in alternate content in sequence. The preliminary goal was merely to produce a slightly altered sbf file (without the mod actually having any benefits.. would be happy if all it did was screw something up, like break a system app) that still was able to be flashed with RSDlite; this initial approach was purely aimed to be a proof of concept test. My reasoning was that if that could actually be accomplished, then my next steps could be geared towards sectioning out and splicing in larger regions of data and exploring different locations on the sbf file. Effectively, my idea was that utilizing this deconstructive methodology I could some how back track until I mapped out what regions could and could not be tampered with; so kinda like determining the base sbf skeleton so to speak and then being able to substitute in data with the confines of that framework.

I never once really thought about hunting down the actual keys with this approach, but more so to get a understanding of the inner workings of these sbf files enough so that we could edit them.

Unfortunately, upon further review, I think that my initial interpretation of how RSA encryption and digital signatures actually work was completely flawed. My molecular cell biology classes had me thinking sbf files could be modified the same way DNA vectors are genetically altered. I literally was thinking about doing it the same way recombinant DNA is made;

• you first recognize a particular sequence,
• you then specifically target it and splice and splice it out utilizing restriction enzymes,
• then you prepare a new strand of DNA which contains the sequence encoding for newly desired trait you which to incorporate
• then you prepare that desired DNA sequence for recombination with the original DNA by adding tail ends which specifically correspond/match-up to the sequence of open spliced ends.
• Lastly, you insert this specially altered DNA into the gap of the original genetic sequence (the gap that you previously created by lysing out specific region) and it combines perfectly because the sequences match up.
• You end up with genetically altered DNA vector that you can then insert into a host cell and it will cause that cell to start producing the new protein (or anything) you encoded for that it previously did not.

I was basically equating hex code read outs to DNA sequences and assuming that everything could work the same way. This however is now to my knowledge, not the case at all.

Correct me if I am wrong, but if you were to edit a single byte on the sbf file, then you will have effectively changed the checksum and therefore broken the digital signature. I do not believe that you can then alter the checksum value itself to account for the change you made because this checksum sequence it checks against to validate the files authenticity is not just arbitrarily placed somewhere on the sbf itself, freely open for you to tamper with, but in actuality, its integral part of the digital signature itself (?) and is governed by the same encryption scheme. Is that really how it works or am I still off?

If it works in that fashion or any way similar to that, then I can definitively tell you right now that my original idea has no chance.

{{ WugFresh }}

 

[aliasxerog]

You can edit the checksum, you just need the private key to sign it.

 

[czerdrill]

@czerdrill
My original intentions with this approach were actually not aimed at finding the unencrypted keys but rather to direct the focus on determining everything else, as in to identify the normal bulk data regions and attempt to splice in alternate content in sequence. The preliminary goal was merely to produce a slightly altered sbf file (without the mod actually having any benefits.. would be happy if all it did was screw something up, like break a system app) that still was able to be flashed with RSDlite; this initial approach was purely aimed to be a proof of concept test. My reasoning was that if that could actually be accomplished, then my next steps could be geared towards sectioning out and splicing in larger regions of data and exploring different locations on the sbf file. Effectively, my idea was that utilizing this deconstructive methodology I could some how back track until I mapped out what regions could and could not be tampered with; so kinda like determing the base sbf skeleton so to speak and then being able to substitute in data with the confines of that framework.

I never once really thought about hunting down the actual keys with this approach, but more so to get a understanding of the inner workings of these sbf files enough so that we could edit them.

Unfortunately, upon further review, I think that my initial interpretation of how RSA encryption and digital signatures actually work was completely flawed. My molecular cell biology classes had me thinking sbf files could be modified the same way DNA vectors are genetically altered. I literally was thinking about doing it the same way recombinant DNA is made;
you first recognize a particular sequence,
you then specifically target it and splice and splice it out utilizing restriction enzymes,
then you prepare a new strand of DNA which contains the sequence encoding for newly desired trait you which to incorporate
then you prepare that desired DNA sequence for recombination with the original DNA by adding tail ends which specifically correspond/match-up to the sequence of open spliced ends.
Lastly, you insert this specially altered DNA into the gap of the original genetic sequence (the gap that you previously created by lysing out specific region) and it combines perfectly because the sequences match up.
You end up with genetically altered DNA vector that you can then insert into a host cell and it will cause that cell to start producing the new protein (or anything) you encoded for that it previously did not.

I was basically equating hex code read outs to DNA sequences and assuming that everything could work the same way. This however is now to my knowledge, not the case at all. Correct me if I am wrong, but if you were to edit a single byte on the sbf file, then you will have effectively changed the checksum and therefore broken the digital signature. I do not believe that you can then alter the checksum value itself to account for the change you made because this checksum sequence it checks against to validate the files authenticity is not just arbitrarily placed somewhere on the sbf itself freely open for you to tamper with, but in actuality is integral part of the digital signature itself and is governed by the same encryption scheme. Is that really how it works or am I still off?

If it works in that fasion or any way similar to that, then I can definitively tell you right now that my original idea has no chance.

{{ WugFresh }}

Pretty much yes. Now I don't know much about how sbfs are made or compiled, but I would think it would be impossible to even package up an sbf that's been edited like that. so you wouldn't even get to the point of it getting rejected by the phone because it would undoubtedly throw an error somewhere during compilation? (absolutely not sure). Regardless of that, even if you were to compile an edited sbf that way, yes, the signature would have been broken by the edit and the phone would reject it.

your DNA example is a good one in theory how you would think it would work, but it's not. well, maybe you could say it like this. in the DNA splice, if you try to do A-G or C-T, you wouldn't have a viable strand. So, that would be the same thing as editing an sbf this way (maybe not...might be a horrible analogy that just confused you more). Point being is Adenine doesn't match up with Guanine, and Cytosine doesn't match up with Thymine (or uracil), and in the same way, an edited sbf wouldn't match up with the signature that the the bootloader expects.

Like I said I know nothing about sbf creation so I don't even know if you'd have to sign them (although I assume you would), but I imagine that editing parts of the sbf would require resigning.

 

[WugFresh]

You can edit the checksum, you just need the private key to sign it.

Oh.. lol. Catch 22. No doubt. Back to square one.

{{ WugFresh }}

 

[czerdrill]

You can edit the checksum, you just need the private key to sign it.

ha there you go...pretty much what i said, in a far more concise and easy to understand way lol

 

[plslowmo]

Nah man, I knew you didn't mean anything by it. I hope I dont mislead people and giving them false hope, it was really meant to be a brainstorm venue on this thread.

Sent from my DROIDX using DroidForums

 

[WugFresh]

@czerdrill
My original intentions with this approach were actually not aimed at finding the unencrypted keys but rather to direct the focus on determining everything else, as in to identify the normal bulk data regions and attempt to splice in alternate content in sequence. The preliminary goal was merely to produce a slightly altered sbf file (without the mod actually having any benefits.. would be happy if all it did was screw something up, like break a system app) that still was able to be flashed with RSDlite; this initial approach was purely aimed to be a proof of concept test. My reasoning was that if that could actually be accomplished, then my next steps could be geared towards sectioning out and splicing in larger regions of data and exploring different locations on the sbf file. Effectively, my idea was that utilizing this deconstructive methodology I could some how back track until I mapped out what regions could and could not be tampered with; so kinda like determing the base sbf skeleton so to speak and then being able to substitute in data with the confines of that framework.

I never once really thought about hunting down the actual keys with this approach, but more so to get a understanding of the inner workings of these sbf files enough so that we could edit them.

Unfortunately, upon further review, I think that my initial interpretation of how RSA encryption and digital signatures actually work was completely flawed. My molecular cell biology classes had me thinking sbf files could be modified the same way DNA vectors are genetically altered. I literally was thinking about doing it the same way recombinant DNA is made;
you first recognize a particular sequence,
you then specifically target it and splice and splice it out utilizing restriction enzymes,
then you prepare a new strand of DNA which contains the sequence encoding for newly desired trait you which to incorporate
then you prepare that desired DNA sequence for recombination with the original DNA by adding tail ends which specifically correspond/match-up to the sequence of open spliced ends.
Lastly, you insert this specially altered DNA into the gap of the original genetic sequence (the gap that you previously created by lysing out specific region) and it combines perfectly because the sequences match up.
You end up with genetically altered DNA vector that you can then insert into a host cell and it will cause that cell to start producing the new protein (or anything) you encoded for that it previously did not.

I was basically equating hex code read outs to DNA sequences and assuming that everything could work the same way. This however is now to my knowledge, not the case at all. Correct me if I am wrong, but if you were to edit a single byte on the sbf file, then you will have effectively changed the checksum and therefore broken the digital signature. I do not believe that you can then alter the checksum value itself to account for the change you made because this checksum sequence it checks against to validate the files authenticity is not just arbitrarily placed somewhere on the sbf itself freely open for you to tamper with, but in actuality is integral part of the digital signature itself and is governed by the same encryption scheme. Is that really how it works or am I still off?

If it works in that fasion or any way similar to that, then I can definitively tell you right now that my original idea has no chance.

{{ WugFresh }}

Pretty much yes. Now I don't know much about how sbfs are made or compiled, but I would think it would be impossible to even package up an sbf that's been edited like that. so you wouldn't even get to the point of it getting rejected by the phone because it would undoubtedly throw an error somewhere during compilation? (absolutely not sure). Regardless of that, even if you were to compile an edited sbf that way, yes, the signature would have been broken by the edit and the phone would reject it.

your DNA example is a good one in theory how you would think it would work, but it's not. well, maybe you could say it like this. in the DNA splice, if you try to do A-G or C-T, you wouldn't have a viable strand. So, that would be the same thing as editing an sbf this way (maybe not...might be a horrible analogy that just confused you more). Point being is Adenine doesn't match up with Guanine, and Cytosine doesn't match up with Thymine (or uracil), and in the same way, an edited sbf wouldn't match up with the signature that the the bootloader expects.

Like I said I know nothing about sbf creation so I don't even know if you'd have to sign them (although I assume you would), but I imagine that editing parts of the sbf would require resigning.

Word. My DNA analogy doesn't hold true but not for reasons you just gave (good try though..lol).
The reason why it doesn't, is because DNA is not RSA encrypted, its open source (lol). All you have to do is match up the sequences correctly and you are golden.

The sbf scenario is different; consider the following:
You couldn't recombine DNA if you got to the point where you were ready to insert the new sequence in but in order to activate the DNA ligase (the enzyme which actually seals the bond) to do its thing, you needed to tell it a password first, because at that point.. there is literally nothing else you can do unless you have that password. With genetic engineering all you have to do is make sure your sequences match up and then the enzymes will perform their function to seal the deal. But with an encryption scheme in place, the private key becomes the new gatekeeper regardless if you know what to edit or how to match things up.

{{ WugFresh }}

 

[czerdrill]

@czerdrill
My original intentions with this approach were actually not aimed at finding the unencrypted keys but rather to direct the focus on determining everything else, as in to identify the normal bulk data regions and attempt to splice in alternate content in sequence. The preliminary goal was merely to produce a slightly altered sbf file (without the mod actually having any benefits.. would be happy if all it did was screw something up, like break a system app) that still was able to be flashed with RSDlite; this initial approach was purely aimed to be a proof of concept test. My reasoning was that if that could actually be accomplished, then my next steps could be geared towards sectioning out and splicing in larger regions of data and exploring different locations on the sbf file. Effectively, my idea was that utilizing this deconstructive methodology I could some how back track until I mapped out what regions could and could not be tampered with; so kinda like determing the base sbf skeleton so to speak and then being able to substitute in data with the confines of that framework.

I never once really thought about hunting down the actual keys with this approach, but more so to get a understanding of the inner workings of these sbf files enough so that we could edit them.

Unfortunately, upon further review, I think that my initial interpretation of how RSA encryption and digital signatures actually work was completely flawed. My molecular cell biology classes had me thinking sbf files could be modified the same way DNA vectors are genetically altered. I literally was thinking about doing it the same way recombinant DNA is made;
you first recognize a particular sequence,
you then specifically target it and splice and splice it out utilizing restriction enzymes,
then you prepare a new strand of DNA which contains the sequence encoding for newly desired trait you which to incorporate
then you prepare that desired DNA sequence for recombination with the original DNA by adding tail ends which specifically correspond/match-up to the sequence of open spliced ends.
Lastly, you insert this specially altered DNA into the gap of the original genetic sequence (the gap that you previously created by lysing out specific region) and it combines perfectly because the sequences match up.
You end up with genetically altered DNA vector that you can then insert into a host cell and it will cause that cell to start producing the new protein (or anything) you encoded for that it previously did not.

I was basically equating hex code read outs to DNA sequences and assuming that everything could work the same way. This however is now to my knowledge, not the case at all. Correct me if I am wrong, but if you were to edit a single byte on the sbf file, then you will have effectively changed the checksum and therefore broken the digital signature. I do not believe that you can then alter the checksum value itself to account for the change you made because this checksum sequence it checks against to validate the files authenticity is not just arbitrarily placed somewhere on the sbf itself freely open for you to tamper with, but in actuality is integral part of the digital signature itself and is governed by the same encryption scheme. Is that really how it works or am I still off?

If it works in that fasion or any way similar to that, then I can definitively tell you right now that my original idea has no chance.

{{ WugFresh }}

Pretty much yes. Now I don't know much about how sbfs are made or compiled, but I would think it would be impossible to even package up an sbf that's been edited like that. so you wouldn't even get to the point of it getting rejected by the phone because it would undoubtedly throw an error somewhere during compilation? (absolutely not sure). Regardless of that, even if you were to compile an edited sbf that way, yes, the signature would have been broken by the edit and the phone would reject it.

your DNA example is a good one in theory how you would think it would work, but it's not. well, maybe you could say it like this. in the DNA splice, if you try to do A-G or C-T, you wouldn't have a viable strand. So, that would be the same thing as editing an sbf this way (maybe not...might be a horrible analogy that just confused you more). Point being is Adenine doesn't match up with Guanine, and Cytosine doesn't match up with Thymine (or uracil), and in the same way, an edited sbf wouldn't match up with the signature that the the bootloader expects.

Like I said I know nothing about sbf creation so I don't even know if you'd have to sign them (although I assume you would), but I imagine that editing parts of the sbf would require resigning.

Word. My DNA analogy doesn't hold true but not for reasons you gave.
The reason why it doesn't, is because DNA is not RSA encrypted, its open source (lol). All you have to do is match up the sequences correctly and you are golden.

The sbf scenario is different; consider the following:
You couldn't recombine DNA if you got to the point where you were ready to insert the new sequence in but in order to activate the DNA ligase (the enzyme which actually seals the bond) to do its thing, you needed to tell it password first because at that point.. there is literally nothing else you can do unless you have that password. With genetic engineering all you have to do is make sure your sequences match up and then enzymes will perform their function to seal the deal. But with an encryption scheme in place, the private key becomes the new gatekeeper regardless if you know what to edit or how to match things up.

{{ WugFresh }}

nicely said and yeah that's it. with DNA if you know ATCG, you can't go wrong. with the sbf you need to know ATCG and the password (the key).

I used the mismatched DNA base pairs as an example to show how the "signature" is broken but that wasn't the best way to do it lol. Your example is more on the money with the ligase needing a password, etc.

 

[WugFresh]

Well this is a bummer. I guess that makes sense though, what would be the point of a digital signature if you could just work around it? I was silly to think it was just like a chunk of data you had to keep somewhere on the sbf... in that case it might as well just be a file called license, like all those programs out there which rely on a license.dat for activation purposes... all to easy to crack.

Well at least I have a better understanding of encryption now... lol.

@czerdrill
Regarding you post about donations, I kind of disagree considering the fact that Koush and Birdman set out to unlock the bootloader and ended up with ClockworkMod. They still built something tangible that works and might not be the real thing but is the second best option we got. If it weren't for their initial mission, they would have never achieved that.

{{ WugFresh }}

 

[plslowmo]

Well there's only one solution left, disassemble the x and dump the nand and OMAP rom. Just joking...

Sent from my DROIDX using DroidForums