[Q] A way to adapt LK to Blackstone? - Touch HD General

Hello all XDA community,
I've got an HTC Blackstone sleeping in my desk and I wondered if any possibilities could be considered to port LK on this device.
Indeed, this bootloader have received many improvements on HTC Leo and now this one can be assimilated as a "native Android device". And the most important thing, I think, is that it is open source.
So, any dev have already worked on it?
I've see that lk can be customized depending of the memory of the device in lk/target/<target_name>/atags.c such as the "startup.txt" of HaRET.
But I don't know exactly what is the compatibility of the MSM 7201A of the device with this bootloader.
I think there are a lot of modifications (screen, display, NAND type,...) to do for adapating lk but, like everything else, a start can be great
Thanks to all answer!

LK already works on the RHOD. (Still being refined, but does work).
A dev needs to pick up a Blackstone and work on porting from RHOD, it's pretty similar.
Or, as I already suggested, if someone has an extra (or unused) Blackstone, ACL will take it and in time should be able to port it pretty easily (in theory). He's working hard on RHOD right now, but I'm betting he would help Blackstone users if someone donated a device to him.
Food for thought.

Related

Newbie: It all got so complicated, so quickly

If you'd be so kind, just to clarify the following.
I've got an Orbit II, with Copilot. Yes it does feel as if one is part of a club, but there's the topset and the thick kids... I'm the latter.
As I understand it, the Hard SPL unlocks the phone, from it being tied to a mobile network, right?
The O2 II isn't locked so then I don't need it, yes?
Therefore, I can either install all the tweaks and tips thus keeping Copilot, or put another ROM, (is this a type of disk image?), with all the tweaks and tips built in, on it.
In which case I'd lose CoPilot, for I'd have written over the device and voided the warranty, to boot, right?
What actually is the difference between a ROM and all the 'tweaks and tips'.
Is it because if you need to Hard SPL (ie unlock a phone from the network), then you don't have any built in functions left, so you couldn't install the Tweaks and Tips, which would in effect bring all the same advantages.
Look, I know Bebe has managed to do a version of WM6.1 which features threaded SMS and everthing, but I'm still not quite with it, I'm afraid.
The wiki entry for "What is a Hard SPL", just says it's one way of not trashing your phone. Not trashing your phone before you attempt what though?
For I've seen mention of the SIM/CID unlocker as if it's a separate entity, indicating they are two distinct things, created for two different tasks.
I like the idea of the phone looking funkier and working better (God knows what the AMMD is for the Video, but I know there are issues with the video, so having that sounds like a good idea as well. Right?)
Whatever it all is, it sounds like it's been a mammoth job/labour of love and has involved the purchase of two new Polaris phones, but beyond that, I'm all at sea.
(Dons bullet proof vest and climbs into protective Pope Mobile)
I think the fact you are asking all these questions juxtaposes that you should not flash your ROM. I myself am in your class and just look on with admiration. With that said, there are many things that you can do to your phone to "spice" things up. I have bought a couple of programs, Astronavigator II, (tells you what the sky at night is above you, My Girlfriend loves it), Fun contact, much more finger friendly than wm6. I also have PZP program. It automatically sets my phone to do things at certain times of the day, i.e at night it switches off, emails and phone calls then do not wake me and GF up, much to her relief! So there you have it, oh btw I have tomtom as have the TC.
The phone works quickly, efficiently and never have to soft reset. 5 years of using WM devices, I have found that idiots like me should just live and let be and use the phone as it is.
This should anser none and all of your questions
Kind Regards,
Will
unfortunately you have discovered HTC
Hey,
I hear ya. I am fat boy too. lol
I can't keep up and these forums use a form o speak, and implications that are not clear. I have no idea of why one of the cubes is called a bunch of letters for instance. unfortunately, we want our phones up to date, and the fastest they can be. But it is not that simple. I agree, I am lost on the spl thing and the sim, but then ??? it is not that clear to me.
Here is how I understand it. It may not be right, but it is an analogy that seems to work. A soft reset is reboot, a hard reset in a wipe/reinstall. As I understand it, the rom is the basic operating system, meaning when you hard reset, that is what loads into memory. Once it is loaded, it can be soft reset ie rebooted without harm. The rom is kept on the device, so when you hard reset, it can reload/reinstall itself without needing to be connected to anything. Disk Image? I guess. If your original rom, from the manufacturer installs copilot with a hard reset, then you will keep copilot. When they cook a rom, they change those installation files permanently. They adjust things, and remove things. they alter hardware drivers per say ie the radio patches you get. If Copilot is not in the cooked rom, then you would lose Copilot. You would need to buy it or download it and install it yourselft. You would have to use a restore disc, hooked to a computer and mobile center, to overwrite a cooked rom back to the original rom in this cases wm6. ROMS are much more of a big deal, as there are bugs and some things don't work as expected. They are faster tho, imho. Tips and tweaks are just that, certain replacements and other alterations. I woul think most tweaks I have seen generally do stay with the device thru soft resets, some don't if you have to hard reset. I keep my tweaks and settings/programs on the storage card incase I have to hard reset. Hope that helps, it may not be correct, but it works for me as a basic understanding level. There is a way to chose what you install as the rom (ie operating system permanently on the phone for hard resets), and i think the term they use is the kitchen. Using the kitchen, you chose this piece of a rom, and that one, etc....all that goes to the permanent part where a hard reset tell it what to read and install. I am not too clear on that one myself. I find using a kitchen fightening and wrought with risk at bricking.
Will has summed it up pretty well.
We buy these phones for what they can do, and they are just not supported by manufacturing like they should be. Our expectations are flavored by the continual upgrades from things like MS and windows upgrades fixing and patching things. I have had two pda (one previous phone). Either manufacturer was the same, limited upgrades and basically no further development on the devices.
It was a harrowing experience to upgrade my phone/pda to wm6 out of fear of bricking it. My phone came with wm2003. Bricking if you don't know, is leaving your device in an usable state...it is caught in limbo somewhere, and will not work.
Advice, wait a while, keep reading. Since things are hard to understand, keep reading and don't be in a hurry. Eventually someone will ask a question, in one forum or another, that inadvertanly answers one of yours. Check out the hacking forums, nice tweaks in there. And yes, they kinda of leave out steps. Keep Pocket Controller, it lets you tweak the registry, and see your device on your desktop. Even MS was impressed, troubleshooting a bluetooth issue. MS loved they could control the pda themselves using remote desktop. MS sent the name of that progie up the chain of command. They loved it. You can screen shot and all sorts of things. It come in handy trying to explain things. Once you feel you can risk losing the phone/device, then consider upgrading to new rom and try some of the tricks/tweaks. I know I don't want to waste 700.00 or more dollars to brick something. I think most of the time, they can get the bricked phone back, but not 100% certain of that. I study the reset and etc procedures and print them out, before I muck with the rom. I consider what I do to the phone very carefully. I was so scared I would ruin my phone.
And the other thing i say, is if you tell people you are a noob at this stuff and have a hard time understanding, they generally won't flame you too hard. Really. Just explain yourself, and give your disclaimer, and they won't be too hard on you. As you have seen, they may not fully explain things as clearly as you like, due think that is just the nature of the people and the way they think, not a personal attack or lack of anything, but they won't be rude.
As you said, this forum is run by the topset, and we are thick ones. They do astounding work and some of us just look up at them and admire. But they will help you. Keep reading, and keep trying to understand, it gets better with time. And don't be in hurry either. I see two post already of people bricking their devices already. And one guy seriously bricked his to the point of no return it seems.
ukdutypaid said:
Therefore, I can either install all the tweaks and tips thus keeping Copilot, or put another ROM, (is this a type of disk image?), with all the tweaks and tips built in, on it.
In which case I'd lose CoPilot, for I'd have written over the device and voided the warranty, to boot, right?
For I've seen mention of the SIM/CID unlocker as if it's a separate entity, indicating they are two distinct things, created for two different tasks.
Click to expand...
Click to collapse
As I understand it (and I've loaded HardSPL + a modified ROM on my Polaris), the SIM/CID unlocker is for those devices that were purchased from a telco and therefore locked to that company (pernicious behaviour, btw, but they offer low purchase prices to tie customers in). If your device was unlocked at purchase, then this issue doesn't bother you.
The HardSPL load is designed to prevent you bricking your device with a crook modified ROM - this obviously pre-supposes that you will load modified ROM's. If you want to do this (ie. try modified ROM's), then loading HardSPL 1st is a no-brainer.
Why would you want to load a modified ROM ? The short answer is that the marketing depts of the manufacturers load the devices with all sorts of fluffy software crap. They do this in the released ROM. So to remove this junk - and have the device fast, responsive and with enough room left to do what you want - the gurus here modify these ROM's. [Of course, some people like the fluff]. The manufacturers also occasionally release ROM upgrades, but development is done mostly in forums like this.
CoPilot 7 ? Yes, flashing a new ROM will kill this, because the DeviceID changes when a new ROM is loaded. But if you visit the CoPilot website before loading a new ROM, you can deactivate your current license and then reactivate it after installing on a "new" device. In fact, CoPilot is one of the few commercial apps to cater for ROM upgrades with honour. CoPilot doesn't care how many devices you install on, just that only one at a time is actually capable of running.
Here are your acronyms to understand what they are doing and talking about. This may not be right, but alot of this came from the Hermes. It seems someone was looking to run linux on his hermes i think. I am still kind of digesting this information now. Remember I told you look around?
Here are your definitions to help you understand.
AKU - Adaptation Kit Update: they usually patch up existing bugs and enable several new features. Each newly released AKU pack retains fixes found in previous versions of AKU
CID lock (aka vendor lock): put on your device by the manufacturer to prevent installation of a ROM not released by them. CID is a vender lock, the post above talks about that. It is placed on you phone to deliberately prevent you from changing the rom. It is vender specific it seems. I assume the Super CID tells the device to ignore that lock or overwrite the vender lock all together, or it might just tell it to ignore the error code. That is what I am seeing. This seems basically related to full administrator priviledges account for the device. it seems the CID was located on a secure area on the radio. People had bad flashing to the radio upgrade and corrupted their CiD essentially bricking some of their phones.
RIL - Radio Interface Layer.
RUU - ROM Upgrade Utility: Its the s/w used on your PC to do a ROM upgrade for your PPC. I assume this can be the default utlity or a kitchen program. The default you can find pictures of, it is generic and just tell you are flashing. The kitchen program, i canceled once, had options to choose.
IPL - Initial Program Loader: Its the bootloader for PPC. It boots up SPL. Bootloader. Basic operations.
SPL - Secondary Program Loader: By inferenece only? Hard SPL then stands for a forced control over the secondary Program layer. You can make it load something else when it boots. It seems the newer factory SLP would want to reference the CID or only properly signed files, thus limiting what you could actually do with your phones.
WWE Edition - World Wide English Edition
XIP - Execute-in-Place
It seems while trying to unlock the Hermes, they were using a radio upgrade and somehow got this Super CID. See above about CID. So it seems there was a reverse engineer done with a legitmate unlocker program. This unlocker program was installing certifcates and changing the device to a lower bootloader it seems. That bootloader ignored the CID or converted it to full priviledges. they also figured out, some bad flashing can be undone....the CID was stored in a secure area on the radio. A bad radio flash corrupted part of the CID. Once they converted to a different bootloader, they could reflash radios...thus unbrick some phones. They have replaced the bootloader with this Hard SLP. The new SLP converts or tells the phone to ignore the CID when upgrading a ROM or other things. It appears HSPL v1.13 also keeps track of bad blocks of memory. That version also reflashes bad blocks or corrupted files with fresh versions as well. It also respecs completely bad blocks, i am thinking that means, the os is not allowed to write there. The you can reflash anything to the device. Or so it seems. But again, depending on how bad you muck up your phone, some things are not repairable.
That is what I am seeing right now. Still reading. It is all out there. Just google the terms above, and slowly you will find the threads and start piecing it together.
Seems this Hard SLP is important for ROM ugrades. Still reading about it. I am post like 500, out of 1000, and trying to keep track of it is difficult. Lots of interjections of what people did wrong. Very confusing.
I did tell you read, read read, and you will find the answers to your questions, it just takes awhile and it hard to understand becuase of the lingo.
v nice. u guys need to read som basic stuffs. it will help u, & u don't have to worry about u,r phone. u can upgrade, u can change things with full confidence. xda-developers have wiki pages, i think it will help much. keep readingggggggg. soru 4 my english
You won't lose your copilot if you use the original HTC ROM....I put the original HTC ROM (which is much better than the O2 ROM)...added a few standard registry tweaks..runs NICE..reinstalled Copilot7 (from the 2577 folder on the SD card) reactivated it..(did not need to deactivate it) and everything is fine. If you need to got back to the original ROM for whatever reason...reflash it and then flash with originalSPL file.
You can reactivate copilot as many times as you like (the only thing I do before reflashing...mor as a precautionary measure...is backup the SD card)
If you use a cooked ROM ..then I think you have to deactivate Copilot and reactivate it on the new install.....but I'm sure the experts will know better.
pistonripper said:
If you use a cooked ROM ..then I think you have to deactivate Copilot and reactivate it on the new install.....but I'm sure the experts will know better.
Click to expand...
Click to collapse
Agreed - I've had to do that a number of times, from both modified ROM changes and device changes, but it's easy and painless.
Thanks for the indulgence...
People, I'd like to thank you for taking the time and trouble to provide your very useful responses. One does read of course and things like lego bricks begin to click into place. I don't even have a car, so quite why I'm so obsessed with CoPilot, I don't know. Okay I giggle when listening to one of the ladies (through headphones), on the bus, but other than that.. lol.
I didn't know you could actually download CoPilot from the site though, I'll check that out. I've 'funked it up' a bit using the HTC Home cab and Slideunlock. Tempted to play with one of the Cube .cabs...(The one it comes with is pretty rubbish if you can't change what the cubes link to and the icons)
Yes, Yes I'll search for the original O2 rom, before I play anymore...
The actual HTC rom, sounds like a safe bet though, cos then you get the proper funky screen..
Don't want to clutter (anywhere actually) the hard core threads with stupido questions. I'll look, I'll read, I'll learn...
As one of you has said, these things aren't toys (lol) and I don't want to be left looking at a $700 £350 quid (non contract Orbit), that I can't use...
I think Bebe wm6.1 is going to stay undownloaded for the time being!
I'll leave the topset, to carry on.. Wouldn't mind getting rid of the "Streaming Media", program mind. Errr, it does/streams what exactly, anything at all?

Android native on HTC Devices

Hey everybody,
some hours ago i had a HTC Magic in my hands, to play arround a little with Android and i'm really impressed. I like the workflow, the Interface and so on.
For some time now, we have the possibility, to run Android on our devices through Haret. So i thought about, wouldn't it be possible, to autoboot Android on let's say a HTC Touch Diamond?
As far as I know (please correct me if I'm wrong), the SPL is some kinda Bootloader, wich after loading Drivers, boots the OS.bin.
If we could get together the Developer of Haret and the guys from the HardSPL Development Crew, wouldn't it be possible, to melt both projects.
This could be like this:
When you boot up the device, you are asked what to boot (Windows / Android or Linux). If you choose Windows, it starts the normal boot process loading the os.bin. If you choose Android, the Haret code is loaded and boots up Android.
Of course the Android port needs a lot of drivers, but if we are that far, developing drivers for the open source Android shouldn't be that hard.
What do you think about this Idea?
I would start developing this myself, if somebody could teach me about SPL and so on.
I run the Android version for the Tilt. The number one main reason why it's not being done is that it's not 100% functional. On the Tilt anyway, the camera, GPS and Bluetooth are not working yet. I'm sure in the long run, the plan would be to build Android ROMs for WM phones.
Yes, that's the main problem...not of being non functional, but of missing drivers.
ice8lue said:
Hey everybody,This could be like this:
When you boot up the device, you are asked what to boot (Windows / Android or Linux). If you choose Windows, it starts the normal boot process loading the os.bin. If you choose Android, the Haret code is loaded and boots up Android.
Click to expand...
Click to collapse
This concept is what I have been dying to have on my Touch Pro.
That would amazing... A dream come true. Needless to say, I think it is a great idea!!!!
Hey guys, what about inventing an perpetuum mobile? Great idea, or not?
Don´t get me wrong, your idea is great, but I think there are reasons, why we don´t see fully working android ports for our loved devices.
Of course there are reasons why we don't have this till now.
We also have reasons why we haven't been on mars...so should we stop trying?
I know this is a hard one, coz there hasn't been ported an OS to devices, they weren't made for, but I also think it's possible

Acer F1 system successfully run Android 2.2

Turn:mikeyangly(Come from:pdafans.com)
Touch screen, and drive signals are not supported, I hope the faithful machine can solve this problem
System Download:rayfile.com/zh-cn/files/4e80a502-973c-11df-abb4-0015c55db73d/
GREat news !! hope its just a question of time for the others drivers!
On my neotouch android doesn't boot. It stays on this:
EDIT (22:05): now it boot. I haven't got in the root of Storage Card .
s200 froyo 2.2
O ye,this is a very great news,incredible ,we jump directly to Froyo 2.2,as you say it is a matter of time and developers now.The waiting has began!
Otherwise phone boots very quck:
-no touch
-no sound
-no keys
-no gsm ...
we hope all will be on soon
good start. hope problems are possible to be solved....
Oh very goog!!
Does tsamolotoff's TS driver works?
its drivers work with ubuntu!
Wow great news!I am waiting for a full working version(rom)
Android just has more free apps than windows..
that would be the only reason i would want android
free apps... oh well
The only reason i would want android is a bunch of games ported for this system. Android for games and WinMob for everything else. and all this stuff in one device. that would be nice
very good.
Why do I have blue screen after 10 seconds working of it?
Because there are many problems to resolve to use android on our s200...The os is not alredy usable like in htc hd2,and our device is not supported like the htc one.So maybe the project for s200 is end.I wish i could use android in my phone,but maybe i will never see a usable interface
This is an exciting good news. Soon we can use the Android system has. Thank you for your efforts.
Sadly theres no kernel/android dev that has an s200, so android partly working on it might never happen, unless a dev picks it up and starts making patches/fixes for the kernel.
Not so good if you think that s200 and hd2 project started togheter,but hd2 after 1 month has a usable android or ubuntu release and our s200 has only a not usable android "desktop".Our device is not supported by comunity as hd2,so correct me if i m wrong,but i think no one still working on android s200 release
Ok guys it has been a month since first post, anyone reckon this is going somewhere? who was developing this in the first place? I am willing and ready to help in any way I can (I have stated this before) if necessary. I have a working s200, but no experience in linux programming, although I could learn some basics if needed.
Maybe we could send some android devs a pm? I mean how hard can it be if our hardware is so similar to the Liquid, AND we already have it running on our processor...?
I have seriously considered leaving the s200 and getting an HD2 by now...
Greets
no news of any progress for a while now...
anyway i never expected a fully working android on our neotouch. theres just not enough guys working on it like on the HD2...
can someone mirror this file please?
i dont want to download & install rayfile's client...
Thanks.
It s a really hard porting job...Hd2 owner has a good partialy stable android port,but as you all know there's 20 times hd2 then s200.The problem on our phone is the restricted comunity support
Well, it seems that when I got my s200 broken nobody raised the banner from my cold hands
Now my device is up and running again, and maybe i'll try to do something more... don't expect ts to work in android, as it's completely functional via tslib, and i don't know droid's architecture to determine why this PoS of an OS can't use it... if you really want it guys, why don't you experiment with sequence of input_abs_* functions within ts worker thread in driver ? There're so many *experts* who make ROMs via kitchens or do fancy icons/pictures - take up your time and learn C / linux kernel... I started with barely basic knowledge of the first (and I was lucky with the fact that there're many pre-coded drivers that simply needed some testing, or with semi- or fully-compatible initialization (many thanks to dcordes, Cotulla and the team))

Device Stage for HD2

Hello Guys,
I'm trying to do a device stage for the HD2, because I think the HD2 is not really good implanted and I want to change this.
The Device Stage is a feature of Windows 7 which bundles all the device informations and functions in one window.
Microsoft released recently a SDK and I got it and tried working a bit.
Now my problems:
First one is that I need the unique hardware id(s) of the HD2. I tried to get it but all I got is:
DOID:TCPIP\WINDOWS_MOBILE_DEVICE
DOID:USB\VID_0BB4&PID_0B40&REV_0000
DOID:USB\VID_0BB4&PID_0B40
The first ID isn't recognised at all and the second and last one do recognise the HD2, but like it seems not all features the phone is capable off.
Do you have infos or tips? Would help me a lot do get a device stage for us all
Below this my very first alpha of the device stage, like I said, just started and have to figure things out.

DX Bootloader encryption key idea

So I had an idea today...I'm sure the geniuses that have gotten the Dx and D2 this far have already tried it; but I cannot find any information on it. What if we tried the good old fashioned trick of cold booting:
Google princeton cold boot. I cannot paste links.
I am going to make my best efforts to try this, but I know there are many people that are far better than I. I will let you know of my results, if I ever achieve any.
I think this is an interesting idea, and have read a lot about this being done on laptops... would be interested to see if this works for the android system...
It would only work if the keys are stored in RAM tho... and I think the keys are hard coded into a chip (thought I heard this somewhere...could be 100% wrong)
Anyways...would be interested to see some of the devs try this...
No idea if this would work but if this could be pulled off it would be a pretty epic hack
This looks to rely on the ability to run custom OS/Software. Since our current hacks involve loading *after* the kernel, I doubt this would work.
Kinda like a chicken before the egg problem.
It requires custom rims on another host. Realistically all you need is for the princeton program to read the ram from a different partition. Im sure it can be modified to mount the phone and read the ram from there.
Kinda as an acknowledgement/off-shoot of what zaphod has said...
What if a second init process could be kicked off to hijack the boot process kinda like what koush did..
If the ram could be dumped quick enough... Would this work? I'm not a dev, but do a lot of sys admin work and understand many of the concepts for kernels, and boot processes...
Just trying to help throw out ideas and get the creative juices florin for those who can develop.
Ps, zaphod, thnx for all ur contributions on this forum, many of ur posts have helped me.a TON
Just Chiming In
That's kind of what unrevoked did:
I know we have completely different phones, but this is basically how they cracked HTC:
They found out that in the booting of the phone, during the init, adb would start, but then immediately get killed off by HTC's init. what they did then was found out that if they inserted an SD card into the phone at the precisely exact time (between when ADB started and got killed off by MOTO) so that it would be read right before ADB was killed by MOTO, it would hang MOTO's init, so they had full adb access during the init process, which allowed them to run the phones STOCK recovery alongside ADB. Firstly it allowed them to get root, then once they got root what they basicall did was kick off a LEGIT system update through the phones recovery and then SWAP it for a payload right in between when the phone finished the key checks and started writing the new system....
I know that we have two different things going on here.... but if they did this, I'm sure we could pull something like swapping kernels during load.....
MAN I wish Unrevoked got and tried to crack the X, but they focus on HTC phones.
Any way to send this idea the devs' way without looking pushy? I think from a technical stand-point this is a worthwhile idea to look into...or at least give some thought to it...
thinking about it further
After thinking about this more I think the answer has to lay in this exploit. We are right in stating that the key is actually burnt into a chip somewhere. However, we must remember that there is some key generation going on during the bootloader phase. Thus: at some point the correct key is stored in memory as the phone correctly boots. If the phone boots, the key is laying someplace in memory. It's just a matter of finding it.
I haven't had time to play with this yet, hopefully I will have some time this week or weekend. I am very confident that this will work, it's just a matter of figuring out how to get the program that reads the memory to look at my phone, not my computer.
lilott8 said:
After thinking about this more I think the answer has to lay in this exploit. We are right in stating that the key is actually burnt into a chip somewhere. However, we must remember that there is some key generation going on during the bootloader phase. Thus: at some point the correct key is stored in memory as the phone correctly boots. If the phone boots, the key is laying someplace in memory. It's just a matter of finding it.
I haven't had time to play with this yet, hopefully I will have some time this week or weekend. I am very confident that this will work, it's just a matter of figuring out how to get the program that reads the memory to look at my phone, not my computer.
Click to expand...
Click to collapse
Liliott,
I'm really glad you are looking into this. I've read about this hack for pc's and think there may actually be something to this. I feel like if we could have something that hijacked the boot process real similar to Koush's recovery then if someone could write a program that would dump NVRAM (I think this is the equivalent to the phone RAM) this would work. With this said, I believe that the devs originally working on cracking the bootloader were able to get NVRAM into "engineering mode" (don't remember the exact terminology off the top of my head)....but I still am thinking this idea should definitely be given more credit and looked into.
I would love to help, but I don't have any dev experience, so I'm somewhat at a loss there....Thanks for pursuing this!
The key you need (presumably an RSA key) wont be stored anywhere on the phone at all.
What happens is that Motorola produce new software for the phone and sign it with their private key (that only Motorola have). This is then sent to the phone. (OTA or whatever they do) The phone verifies the signature using a public key burned into the ROM of the phone (i.e. you cant change it without physically modifying the hardware somehow)
The best hope to break the bootloader on this phone is to reverse engineer it and look for an explot, as has been done on Moto phones in the past (various Motorola MOTOMAGX linux phones have been cracked open this way)
jfwfreo said:
The key you need (presumably an RSA key) wont be stored anywhere on the phone at all.
What happens is that Motorola produce new software for the phone and sign it with their private key (that only Motorola have). This is then sent to the phone. (OTA or whatever they do) The phone verifies the signature using a public key burned into the ROM of the phone (i.e. you cant change it without physically modifying the hardware somehow)
The best hope to break the bootloader on this phone is to reverse engineer it and look for an explot, as has been done on Moto phones in the past (various Motorola MOTOMAGX linux phones have been cracked open this way)
Click to expand...
Click to collapse
Question:
Ok, I know that this will pretty much fall flat, but I have to ask. The Milestone, and OG Droid are pretty much the same phone. Do they have the same boot loader, just unlocked? If so is it the same as the X? The reason I'm asking is it might be easier to crack the Droid since it's already unlocked?
It might be like looking at the lock from inside out trying to figure out how it opens, vs trying to open the lock by looking at it from the outside.
Also, does the MOTO use "goldkeys" like HTC did at one point in time, or have they moved on from that?
On another point, MOTO changed their keys from 2.1 to 2.2, and the phone accepted them. That tells me that it's possible. How much time that will take, I don't know.
Finally, is there any way to "intercept" the process like unrevoked did? I mean if we could get adb working while recovery is working, we could start the recovery process using a legit OTA, and overwrite the zip through adb AFTER verification and before the actual copying. That shouldn't set off the fuse, right?
ideas?
dreamersipaq said:
Question:
Ok, I know that this will pretty much fall flat, but I have to ask. The Milestone, and OG Droid are pretty much the same phone. Do they have the same boot loader, just unlocked? If so is it the same as the X? The reason I'm asking is it might be easier to crack the Droid since it's already unlocked?
It might be like looking at the lock from inside out trying to figure out how it opens, vs trying to open the lock by looking at it from the outside.
Also, does the MOTO use "goldkeys" like HTC did at one point in time, or have they moved on from that?
On another point, MOTO changed their keys from 2.1 to 2.2, and the phone accepted them. That tells me that it's possible. How much time that will take, I don't know.
Finally, is there any way to "intercept" the process like unrevoked did? I mean if we could get adb working while recovery is working, we could start the recovery process using a legit OTA, and overwrite the zip through adb AFTER verification and before the actual copying. That shouldn't set off the fuse, right?
ideas?
Click to expand...
Click to collapse
The Milestone has a locked bootloader, and hasn't been cracked for a year.
Sent from Eris with Froyo
TheSonicEmerald said:
The Milestone has a locked bootloader, and hasn't been cracked for a year.
Sent from Eris with Froyo
Click to expand...
Click to collapse
I really am not trying to sound (too) rude when I say this, but
Did you even READ my whole post?
Yes, the Milestone is locked, but the Droid (the Milestone's US twin) is not.
*Golf clap*
Gotta love it when people reply to a post without even reading a few sentances of the post they are directly replying to. It is understood that the Milestone's bootloader is locked, he was questioning how close the hardware and programming were between the OD (Original Droid) and Milestone aside from the lock being activated in the Milestone. It is the general consensus that the same lock and efuse functions exist in the OD but they are not activated. If this is true then it might be beneficial to see if any of the developers out there with a spare OD test to see if they can figure out how to activate the lock on an OD and then potentially have a better understanding of what might be involved with de-activating it.
Thanks!!!
JinxtPhoto said:
*Golf clap*
Gotta love it when people reply to a post without even reading a few sentances of the post they are directly replying to. It is understood that the Milestone's bootloader is locked, he was questioning how close the hardware and programming were between the OD (Original Droid) and Milestone aside from the lock being activated in the Milestone. It is the general consensus that the same lock and efuse functions exist in the OD but they are not activated. If this is true then it might be beneficial to see if any of the developers out there with a spare OD test to see if they can figure out how to activate the lock on an OD and then potentially have a better understanding of what might be involved with de-activating it.
Click to expand...
Click to collapse
rant
*Bow*
I'm glad that there are still people out there that have a reading comprehension above that of a wet mop. I won't insult them and say they have a low IQ though
I hate it when you take the time to put something that you though about up and someone comes along, reads the first sentence, and (without making any effort to finish the paragraph or REALLY think about what the person is trying to say) spew up crap equivalent to that of the "First" post on blog comment boards.....
/rant
Any haxzors? is this liable, possible, waste of time?
*please don't reply with "waste of time". give us some reasoning, otherwise your post does not help us at all*
The reason it might now
The reason why it actually might not fail is this:
When the system boots, it runs it magic RSA/PGP/AES encryption. It then takes that and compares that to its bootloader routine that it loads. Where does it store the bootloader encryption result to compare to the system boot key? If you guessed memory you would be correct. Now if it stays in memory we will have the golden ticket. If Motorola is smart, and wipe that part of the memory upon OS boot, then it's a matter of timing. If we can get that key, we can, potentially, intercept the bootloader, present the key that we stole and boot our own bootloader/cooked rom.
I think there is quite a bit of potential here.
*Clapping continued...*
I'm glad to see more people finally chiming in on this topic. Call me naive...but when it comes to the dev communities, it seems like "where there's a will...there's a way"
They had made decent progress on cracking this (kinda...) maybe this idea is one that should be looked into (probably said this like 5x in this thread now...oh well)
Thank you to dreamerispaq and Jinxt, appreciate you guys throwing some comments in here
did the release of the 2.2 SBF help at all? If there was a kernel change from 2.1 to 2.2, wouldn't a method be inside of the SBF? Is there any way to hijack the SBF to allow installation of a custom Kernel and ROM?
Shouldn't there basically be an entire phone image inside of the SBF file? If so, would it be possible to alter pieces of that to create some kind of exploit, or use RSD Lite itself and altered SBF's to load up custom kernels and ROMS?
I'm just chucking stones blindly here, I know this is way above my skill level, but I can't help thinking that a full SBF should help similar to the way you can pull the system image from an HTC RUU.
giventofly17 said:
did the release of the 2.2 SBF help at all? If there was a kernel change from 2.1 to 2.2, wouldn't a method be inside of the SBF? Is there any way to hijack the SBF to allow installation of a custom Kernel and ROM?
Shouldn't there basically be an entire phone image inside of the SBF file? If so, would it be possible to alter pieces of that to create some kind of exploit, or use RSD Lite itself and altered SBF's to load up custom kernels and ROMS?
I'm just chucking stones blindly here, I know this is way above my skill level, but I can't help thinking that a full SBF should help similar to the way you can pull the system image from an HTC RUU.
Click to expand...
Click to collapse
Unfortunately, I don't think so. The issue is that both sets of keys are probably hashed and encrypted.... so even if we pulled out the private key out of the SBF that motorolla used, we'd have to brute force it to decrypt it. If, let's say they were smart and used something like RSA as stated above, it'd take a super computer a couple of decades to crack it.
A brute force attack is not going to be helpful here I'm afraid. I'ts going to be more of a lets look at the code, and see if we can find a flaw somewhere in moto's coding that we can use to our advantage.
That's why I recommended looking at the OD. If it shares the same bootloaded, it's already uncloked. Maybe we could take it, reverse engineer it, and look at the calls it makes, where it looks for files, what order it loads things in, etc.... THIS would be more beneficial IMHO.

Categories

Resources