Possible Ways to Crack the Bootloader

[plslowmo]

I'll run a log during a sbf later tonight, at the very least it might be able to give some clues for kexec.

Sent from my DROIDX using DroidForums

 

[pecord]

Am I the only one who thinks it is odd that we can used RSDLite to sbf back to Froyo after upgrading to Gingerbread? Could there be something to that?

It's because it was a soak test. Like a RC basically. I bet when the OTA drops, the bootloader will be updated. Its the same now so that testers can can go back to froyo if they need to.

{{ WugFresh }}

Another crazy idea, couldn't we compare aosp froyo and aosp gingerbread, see whats different and do the same with the moto releases. By knowing what's different and the same we should be able to remove alot of it and whats left would be key's plus moto blur right? Just another idea.

 

[13th angel]

Not if your using 2 different aosp's. Aosp is stock google, not stock moto so it won't have the keys or any blur. The majority of the files would be different so that would end up leaving most of the files.

Sent from my Liberated D2G

 

[fmkaiba]

One if us needs to get a job working at motor, and get access to.the keys for all locked motor devices. How hard could it be?

</sarcasm>

Sent from my DROIDX using Tapatalk

 

[plslowmo]

So an update on what we're working on with USB sniffing, I now using a program called Device Monitoring Studio and I run it when I flash a SBF. It is showing me literally all the data being transferred to the phone. What me and WugFresh are looking for is some clues to the key that signs the SBF as it was from Motorola. That way we can build a SBF with custom kernels and such.

Its alot of data to sift through, but one thing has caught my interest....

2E 4F
3D 4D 6F 74 6F 72 6F 6C 61 20 49 6E 63 2C 20 4F
55 3D 4D 6F 74 6F 72 6F 6C 61 20 50 4B 49 2C 20
43 4E 3D 48 41 42 20 43 41 20 34 34 37 4A E5 EF
4A 67 1D 2B BA 01 00 04 39 4F 3D 4D 6F 74 6F 72
6F 6C 61 20 49 6E 63 2C 20 4F 55 3D 4D 6F 74 6F
72 6F 6C 61 20 50 4B 49 2C 20 43 4E 3D 43 53 46
20 43 41

.O
=Motorola Inc, O
U=Motorola PKI,
CN=HAB CA 447Jåï
Jg.+º...9O=Motor
ola Inc, OU=Moto
rola PKI, CN=CSF
CA


And there's another 100 references to PKI, RSA public, and private keys.
Other devices have been cracked using hardware as opposed to hacking into it, most recently that guy who found the RSA private key for the Apple Airport express. I don't know if any Dev's have even tried taking this approach before but I think I shows some promise.

 

[pecord]

So an update on what we're working on with USB sniffing, I now using a program called Device Monitoring Studio and I run it when I flash a SBF. It is showing me literally all the data being transferred to the phone. What me and WugFresh are looking for is some clues to the key that signs the SBF as it was from Motorola. That way we can build a SBF with custom kernels and such.

Its alot of data to sift through, but one thing has caught my interest....

2E 4F
3D 4D 6F 74 6F 72 6F 6C 61 20 49 6E 63 2C 20 4F
55 3D 4D 6F 74 6F 72 6F 6C 61 20 50 4B 49 2C 20
43 4E 3D 48 41 42 20 43 41 20 34 34 37 4A E5 EF
4A 67 1D 2B BA 01 00 04 39 4F 3D 4D 6F 74 6F 72
6F 6C 61 20 49 6E 63 2C 20 4F 55 3D 4D 6F 74 6F
72 6F 6C 61 20 50 4B 49 2C 20 43 4E 3D 43 53 46
20 43 41

.O
=Motorola Inc, O
U=Motorola PKI,
CN=HAB CA 447Jåï
Jg.+º...9O=Motor
ola Inc, OU=Moto
rola PKI, CN=CSF
CA


And there's another 100 references to PKI, RSA public, and private keys.
Other devices have been cracked using hardware as opposed to hacking into it, most recently that guy who found the RSA private key for the Apple Airport express. I don't know if any Dev's have even tried taking this approach before but I think I shows some promise.

Can you post the log? What would be the next step?

 

[plslowmo]

The log is about 308MB, I don't know how much bandwidth dropbox will let me use distributing it. I would suggest getting the program I mentioned earlier and running it during an SBF, it would probably be quicker than trying to download the log I made.

Whats left is analyzing the data in the log, which is gigantic. I'm doing some research into security because even if I saw a key or certificates in there, I probably wouldn't know what I'm looking at. I'm kinda waiting on someone with a little more technical expertise to chime in here.

 

[plslowmo]

2E 4F
3D 4D 6F 74 6F 72 6F 6C 61 20 49 6E 63 2C 20 4F
55 3D 4D 6F 74 6F 72 6F 6C 61 20 50 4B 49 2C 20
43 4E 3D 48 41 42 20 43 41 20 34 34 37 4A E5 EF
4A 67 1D 2B BA 01 00 04 39 4F 3D 4D 6F 74 6F 72
6F 6C 61 20 49 6E 63 2C 20 4F 55 3D 4D 6F 74 6F
72 6F 6C 61 20 50 4B 49 2C 20 43 4E 3D 43 53 46
20 43 41

.O
=Motorola Inc, O
U=Motorola PKI,
CN=HAB CA 447Jåï
Jg.+º...9O=Motor
ola Inc, OU=Moto
rola PKI, CN=CSF
CA
.

Now I see that is a X.509 certificate.

 

[WugFresh]

I have been looking into what we last discussed pslowmo... I think I was being way to optimistic about this approach. There is no means for us to go about unpacking the sbf to my knowledge, and the key is undoubtedly encrypted in a matter that will prevent us from getting what we need from one of these sniffer programs. What I have been think of though is something else....

What if we could effectively stall out RSDlite during a point in the flash when its transferring bulk data and direct alternate data (in sequence) to transfer to the same open address... would it still need to be signed... is the port created exclusively with RSDlite, or with the computer...? I really don't know about this... but after today I have to say that my optimism kinda tapered off regarding this approach.

Maybe we could sbf to an emulator rather than a physical device?

We need a way to either trick the phone into thinking that data is coming from RSDlite, or trick RSDlite to think its transferring data to a phone.... because regardless how much we know... the certificate is useless if we can't actually access or implement it. We need a way to actually capture the bytes of data.. not just the logs.

{{ WugFresh }}

 

[BackSeatSuicide]

I don't know alot about doing this, I do know coding, but anyways, even tho I don't know much about androids source code and Motos bootloader, the idea you have about using RSDlite actually makes sense and I think its worth a shot. On another note, I was thinking that all of us that want the moto bootloader unlocked (which there's thousands of us) should all put a 1$ in an account and try to just bribe some at moto to help us, or even just moto themselves to unlock it, lol, if all of put a 1$ in, it would add up to like thousands, maybe even hundreds of thousands. That has to be motivation for someone that works at motor and knows how the seceret to unlocking the bootloader lol just a crazy thought I figured I would share. I do have faith that this will be figured out. Harder things then this have been hacked so I honestly think its just a matter of time, ya know.

Sent using my Droid X, Powered by Rubix Focused 2.0.1

 

[plslowmo]

I agree that we might have to use different methods. I am litteraly capturing all the bytes being transfered.

Sent from my DROIDX using DroidForums

 

[Snow02]

The issue is that the information you need you can't get that way. Your best bet would be to read what's being loaded into memory at boot, when the boot image is being verified. Even then, you probably wouldn't get anything useful.

 

[plslowmo]

Im not looking to open up the bootloader, just trying to figure out how to get the bootloader to think that something is legit. When I get home Ill post the the entire cert(what I think is one at least) and see if anyone can make sense of it. Either way, it might not matter, theres rumors that Moto might pull a sony and let us unlock it at our own risk.

Sent from my DROIDX using DroidForums

 

[plslowmo]

Snow I see what you're saying about reading what is being written into memory at boot. But essentially I am looking at the information in the most raw form, that will be eventually be used in the checking process at boot.

Sent from my DROIDX using DroidForums

 

[ClumsyNinja21]

plslowmo,
My question is on the newest GB build. P3 already rooted it in three steps and blah blah blah you know the rest. This is purely "how come" thinking but why can't the ota zip that is obviously signed by moto be modified? The kernel parts and mbm are pretty obvious as I looked thru it. So can't the kernel parts be swapped out with custom kernel parts and repackaged into the ota zip much like p3 did for the rooting process? Or is there a kernel signature that the bootloader looks to match? I don't know but I want to know.