Here is the current bootloader status from @nenolod He is one of the people working on it along with @_mrbirdman_
from Nenolod's post here... http://nenolod.net/~nenolod/sholes/README
from Nenolod's post here... http://nenolod.net/~nenolod/sholes/README
Greetings!
Current status is something like:
0% | ***********************************------------------ | 100%
In other words, we have a general idea of how to achieve bootloader
unlock on these devices, but this has not quite yet culminated into
usable code. That's where you guys will be coming into this in the
next day or two.
We are presently looking for QMI protocol documentation so we can
interact with the radio directly. RadioComm is not useful for what
we want, as it's a Motorola tool and isn't going to show us the secure
area of the radio's NVRAM.
If you would like to watch, then join us on IRC at irc.freenode.net
#sholesunlock. We will op-moderate the channel while we are discussing
to ensure high signal-to-noise quality while allowing contributions of
value to be added to the discussion.
We are also looking for someone to write a JTAG guide for this hardware.
JTAG will, in theory, allow us to unbrick phones that we have replaced
mbmloader on, should our theories be inaccurate.
This should answer some questions you may have and such:
Q: When can I haz unlock? Must haz 9.001THz overclock ROM!!!
A: NVRAM dump tools will happen first, then we will release an exploit. (In the meantime consider that most actual performance issues are from the scheduler and fixing them has already been covered on my blog, which you can do just by rooting your phone.)
Q: How does this work? Why are you attacking the BP?
A: It is well known in the mobile phone industry that the safest place to store secret data is in the BP's NVRAM area. (Well, really, the BP's NVRAM is just a file in the EFS structure now, but...)
Q: Ok, you get access to the BP. What happens next?
A: Replacing the checksum on mbmloader with 0xFF or 0x00 should disable the security checks, allowing us to replace it.
Q: Ah, so once replaced, mbmloader will be unlocked then, right?
A: Yes, which means we will be able to flash a new mbm image onto the MTD. Specifically one from a dev phone.
Q: So once a dev phone MBM is flashed, then what?
A: Then the phone is unlocked as far as eFuse and such go. This allows the flashing of custom boot.img, recovery etc. Custom ROMs are already possible with Koush's hacked up recovery that runs in /system.
With Milestone and Charm it will be more tricky - nobody on this team has
access to a dev Milestone.
Q: So what is protected by the eFuse anyway?
A: mbmloader and nothing else. mbm enforces it's own protections completely in software.
Q: What is x-loader?
A: In OMAP devices, x-loader is the usual bootstrap for uBoot, much like mbmloader is the bootstrap for mbm. Sholes hardware uses mbmloader+mbm instead of x-loader+uBoot as it contains their verification code.
Q: What is that bootsys.s file?
A: That is template platform initialization code for the MSM6k series AP from Qualcomm. mbmloader is based on similar code from Qualcomm, dating back to previous collaborations between Motorola and Qualcomm.
Q: Does that mean that the underlying code used by RSDlite is also written by Qualcomm?
A: Not sure, don't really care. The protocol RSDlite uses to speak to mbmloader is nearly identical though. We also have a sample implementation of that protocol as implemented device-side.
Q: What about the OMAP processor? It could put the sha1sum back after verification!
A: What about it? It could, *but* the calculated sha1sum would be based on the replaced data anyway. There isn't a checksum burned into the ROM on the OMAP, because that would make updating the bootloader software impossible. Anyone who says otherwise has no understanding of the lack of cost benefit that would produce.
Q: I got banned from the IRC channel.
A: That is too bad. Do not complain to freenode staff about it, as they are not going to unban you. If you promise to stop trolling, /msg someone on IRC and we will give you a second chance.
Q: What about the security on Motorola's Android 1.6 devices?
A: The CLIQ and Ming phones are running on a different platform and are generally uninteresting to us.
Q: So why are you guys doing this?
A: Because software freedom is important - and Motorola should have embraced it instead of taken advantage of the Android ecosystem. What they are in effect doing is selling hardware that is misleading to consumers. We feel that it is necessary to correct this in order to empower consumers to take full advantage of free software on their phones.
Last edited:
Facebook
Twitter
Instagram