[BOOTLOADER] Locked bootloader research and news [Updated: 7/16/2012]
- Thread starter AdamLange
- Start date
Read the last post on that thread...
Sent from my DROID X2 using xda app-developers app
"Do you need help getting adb installed or just the instructions on how to run it?"
you're going to have to clarify, I don't understand, it looks to me like like nobody has taken him in and really tried to extract the files
Invisiblek already ran through a phone with the same screen, its as locked as the rest of ours
Sent from my DROID X2 using xda app-developers app
Developing right now:
JackpotClavin and Invisiblek have successfully loaded a custom kernel using a modified recovery ramdisk. It's still very early but this is excellent news for us. As it stands, this method wipes ClockworkMod and requires the recovery key combination on every boot, but those issues can probably both be overcome with custom scripts.
Stay tuned guys...and mash those two guys' Thanks buttons!
JackpotClavin and Invisiblek have successfully loaded a custom kernel using a modified recovery ramdisk. It's still very early but this is excellent news for us. As it stands, this method wipes ClockworkMod and requires the recovery key combination on every boot, but those issues can probably both be overcome with custom scripts.
Stay tuned guys...and mash those two guys' Thanks buttons!
lol that is why you wait for a few days while everything plays out. no need to over react like the wife does
Invisiblek succesfully booted to android using "adb reboot recovery" with his modified recovery.img.
Basically we made it look as if going to recovery, but actually continuing onto boot.img.
indeed, I can't believe how many people are over-reacting, have you no faith in our development guys? do you have to be handed CM/AOSP on a silver platter days before the device is even released? If so you chose the wrong device to begin with!
thats not 100% accurate
i flashed a modified boot.img to our recovery partition (/dev/block/mmcblk0p18)
then rebooted into recovery
it booted up into android using this modified boot.img
i don't plan for this to be of any real use to us though. proof of concept really
we need our access to /dev/block/mmcblk0p7 (where our stock boot.img actually resided)
thing is, we can flash to mmcblk0p7 just fine, but it wont boot (wont do anything actually other than let you get back into odin mode, where you can re-flash the stock boot image, or it gives you this when you try to boot android or recovery: http://i.imgur.com/Ci0gY.png )
rest assured. this is being worked on...
I am definitely hopeful and grateful for your work!! You guys are awesome. :good:
I'm no phone software developer, so bear with me here:
On the "Verizon" side of the phone, you cannot put in a custom bootloader because it's checked somewhere else in the system. As well as you can't load anything because of said bootloader. So, the idea is to run a NEW bootloader and image from the "recovery" side of the phone. As a proof of concept it works, but was just to prove you could do the new bootloader. However, you cannot USE said bootloader because when you would write over the stock boot image, something says "oh hell no" on the Verizon side of things. Correct?
Under these assumptions, would either of the following be possible:
A "dualboot" of sorts? I'm assuming no because you can't boot from mmcblk0p7. Why can't you boot from it though? Is there no read/write access or what? If it was possible, could you remove the verizon side boot.img completely and put a custom rom ON the verizon side, and boot into it using the recovery side? Or is the rom itself being checked by more than the boot.img?
Alternatively, if that's not possible, I would be willing to try the next idea once I receive my SIII. Is it possible to just wipe everything on the phone? Literally everything except Odin pushing. Kernel, boot, signed code that's been hidden, whatever. Everything but the ability to push **** via Odin. If so, can you then load the contents of a variant S3 onto the phone? IE, AT&T, Tmobile, etc. I'm aware kernel issues would arise and such, but it'd be more as a proof of concept. If that was possible, could you theoretically take the drivers/kernel or whatever you want to call it that make the Verizon version work, from a rooted Verizon SIII, and futz with it until you had a functional Verizon S3 running off of competitor boot.img and all that jazz?
I know, the ideas are probably stupid, but it's what I can contribute.
I'm thinking a script to hijack the boot process. Something like this which can replace a binary called on boot by the init scripts http://pastebin.com/V61Fc3iZ The Motorola 2nd-init devices use a binary hijack to do what they want. (They use logwrapper)
Basically, that script checks to see if the stock kernel is the one that booted. If it is, it will reboot recovery to ensure that the custom kernel is booted every time (like the locked bootloader isn't even there)
I think some of the over reacting is justified because if a company truly wants to lock down a bootloader with encryption, it won't be broken. I don't think a single encrypted bootloader in an android device has ever been broken. If it turns out to be something different, like S-OFF on HTC devices or some such then that's one thing. An encrypted bootloader is something else entirely and would have a lot of implications to our enjoyment of these devices. Namely it would mean running anything other than the stock kernel would be like running a VM in an underpowered PC. We could lie to ourselves and say that it was OK, but that's about it.
Jesus, Verizon. This is ass. Can't cancel my order without losing unlimited data on my next phone, so I'm stuck with a locked bootloader? FFS Verizon...
Mad props to JackpotClavin and Invisiblek for working on this though, gives me hope
Mad props to JackpotClavin and Invisiblek for working on this though, gives me hope
TO be clear, over-reacting by definition is never OK. Honestly, after a few OTA updates, my Charge was really nice on completely stock firmware, only had it rooted to get that extra functionality out of it. With a custom launcher like ADW you can make it look and behave differently. It's just not the end of the world.....would I like to see it completely open? Sure. Is it enough to scream OMG the sky is falling and run around in circles within the first few hours of it being in the developers hands? Heck no. If I wanted a fully open device from day one I would have bought a GNex but then I would have to deal with 2010 technology.....which I am not willing to do.
Thanks so much for working this, whatever the outcome, this at least gives us hope that all is not lost when it comes to future customizations of this device.
I'm trying to understand the terminology here - is this breakout accurate, please? :
- ooofest
Similar threads
- Locked
Top Liked Posts
-
There are no posts matching your filters.
-
67
thats not 100% accurate
i flashed a modified boot.img to our recovery partition (/dev/block/mmcblk0p18)
then rebooted into recovery
it booted up into android using this modified boot.img
i don't plan for this to be of any real use to us though. proof of concept really
we need our access to /dev/block/mmcblk0p7 (where our stock boot.img actually resided)
thing is, we can flash to mmcblk0p7 just fine, but it wont boot (wont do anything actually other than let you get back into odin mode, where you can re-flash the stock boot image, or it gives you this when you try to boot android or recovery: http://i.imgur.com/Ci0gY.png )
rest assured. this is being worked on...39Since this is a news thread...
It was reported in IRC within the past hour or so that supposedly BOTH kexec is likely working and noobnl (whom many of you may know from his work with AOSP ROMs) has stated that the RIL has been cracked
To those who don't know what that means, kexec chainloads kernels (in simplest terms, the custom kernel loads on top of the stock kernel AFTER the bootloader checks to make sure the stock kernel has been unmodified). This was necessary if one wanted to run a non-Touchwiz ROM (such as CM, AOKP, etc) or if they just wanted to run an overclocked, undervolted kernel.
The RIL is essentially the radio. It was also needed to run a non-Touchwiz ROM and now opens the door to Jelly Bean ROMs.
There is still working/testing to be done, and there are no ETAs, so don't bug the devs. They're actively working on it so let them do their thing.
What a roller coaster of a weekend36Since locked Verizon SGS3 is now the main problem, i'v decided to split my kernel thread to separate one that focus directly on unlocking bootloader and progress in that matter.
Summary of the problem
Verizon model is protected from flashing unsigned/modified boot.img and recovery.img. Which means there is no known root method as for now for SCH-I535.
And that is where our adventure starts ....
Rooted stock boot.img issue:
CWM Recovery.img flash issue:
Research status: 50%
+ 20% - Some devs stated that RIL is hacked and there is also sucessfull Kexec implentation in works - http://xdaforums.com/showpost.php?p=28484191&postcount=262 Stay tuned for more news. Kexec proof-of-concept thread: http://xdaforums.com/showthread.php?t=1760678
+ 20% - phone can boot from unsigned boot.img flashed to recovery partition, this will leave you without recovery and requires to boot-trough-recovery every time u rebooting phone! (thanx invisiblek)
Links: http://xdaforums.com/showpost.php?p=28420589&postcount=47 , http://pastebin.com/eARk7r48
+ 10% - phone rooted trough system.img tricks -> http://xdaforums.com/showthread.php?t=1756885 (by invisiblek)
ROM analysys:
boot.img -> signed
recovery.img -> signed
system.img -> not signed
cache.img -> not signed
Update [7/7/2012]
News about locked Verizon model is spreading over the websites and main tech-related portals. Hopefully we will get some detailed info soon.
Update [7/7/2012]
It looks like it has been rooted by using system.img trick (system.img is not signed)
http://xdaforums.com/showthread.php?t=1756885
Enjoy! and thanx to invisiblek good job!
Update [07/15/2012] VZN insider confirmed this is not a true info
One of thread members chatted with verizon reps over mail & chat and got info that there may be possible unlocker released for bootloader at vzn locked phones. Here's the screenshots of chat: http://i.imgur.com/0lX3o.png , http://i.imgur.com/ULA4X.png
At this is not confirmed yet officialy, it may be interesting finding.
Update [07/15/2012]
Adam Outler posted he's own research info in separated thread, read it. It may help a bit -> http://xdaforums.com/showthread.php?t=1769411
Update [07/16/2012]
Galaxy S III Verizon Developer edition shows up on Samsung Website! -> http://www.samsung.com/us/mobile/cell-phones/SCH-I535MBCVZW
Thanks!29Developing right now:
JackpotClavin and Invisiblek have successfully loaded a custom kernel using a modified recovery ramdisk. It's still very early but this is excellent news for us. As it stands, this method wipes ClockworkMod and requires the recovery key combination on every boot, but those issues can probably both be overcome with custom scripts.
Stay tuned guys...and mash those two guys' Thanks buttons!24
And your post also.
On a good note while i was digging around last night through the source code I did notice something really nice about the SGSIII that should make you all very happy. As the guys at epic have noted, the kexec flag is marked, meaning that kexec can crash the existing kernel with one of its own. Now what does that mean you may ask. I'm glad you asked.
For those of you that do not know there are 5 primary partitions that are contained on most phones and android devices:
- X-Loader
This partition is usually the partition with the most basic hardware inits such as base gpio (buttons) and power toggles - bootloader
This is the partition that contains what most of us as dev's hate the most, the dreaded boot signature, and boot instructions. When a bootloader is locked down it can be because of either a hardware lock, see OMAP4 processors Sec_On Pin, or a software lock, HTC's S-Off. When a bootloader is said to be locked, it can have two reasons for this, a signed header or an encryption algorithm on the entire partition. - recovery
This partition is the one every one loves to see Clockwork Mod on. When not signed the partition can be flashed and used. ONE THING TO NOTE HERE IS THAT WHEN YOU USE THIS THREAD, YOU ARE SHOWING THAT THIS IS NOT SIGNED, Or the signature is not checked!!! This is intersting because it its self may show a security hole. The recovery might be what checks the CWM recovery flash images signature. - boot
Perhaps one of the most interesting partitions on android devices. The boot partitions contains the binary for the kernel, and the inframs for the initilization of the os. This partition in this case has said to be signed, with a signature check in the bootloader that checks the validity of a boot partition, meaning there is no changing this. - system
Contains most of the information on the OS. At this point all the framework and android settings get loaded. This partition is not signed, meaning we can modify to our will - userdata
Contains the userdata, such as games and such
Now one thing to note is that there are two initialzation points, the first of which occurs in the boot parition and the second of which is in the system's /etc/init files. One thing that i would be interested in seeing is if you were to use this place to load in a new partition or an SD OS. for example:
system1 partition init:
system2 partition can then have an init that mounts a block partition from the sdcard onto the system partition.Code:kexec -l /sdcard/kernel --reuse-cmdline --ramdisk=/sdcard/ramdisk
Code:mount /dev/block/mmc1... /system
Now what does it all mean? This current method means that we can reload a compleatly new os onto a devices kernel and all. AKA Jelly Bean.
For those dev which hope to find a way to make it work i point you to the following posts:
2nd-init can be used for a second init after the first one to allow for kexec to be run (might not need this)
kexec for ARM I might have to modify some kernel memory allocation issues but it should work none the less with the flag. - X-Loader
