Related
Hey all
A little background :
I have a Nexus and a Desire. Both phones are pretty much identical when you look at the hardware. The Desire (GSM) version has a way to repartition its NAND chip in order to resize the /system , /data and /cache partitions on the device. Details can be found in alpharev. The method requires 2 hacks to be implemented,
1. to unlock the security and obtain s-off status
2. to fastboot flash a modified hboot that repartitions the NAND.
My question is:
Is it possible for us to do the same with the N1, seeing that with just "fastboot oem unlock", we can flash anything we want from the fastboot interface, negating the need to implement the first part of the alpharev hack.
all we need is a modified hboot image.
Check the alpharev page for the 4 choices of partition sizes.
str4vag said:
Hey all
A little background :
I have a Nexus and a Desire. Both phones are pretty much identical when you look at the hardware. The Desire (GSM) version has a way to repartition its NAND chip in order to resize the /system , /data and /cache partitions on the device. Details can be found in alpharev. The method requires 2 hacks to be implemented,
1. to unlock the security and obtain s-off status
2. to fastboot flash a modified hboot that repartitions the NAND.
My question is:
Is it possible for us to do the same with the N1, seeing that with just "fastboot oem unlock", we can flash anything we want from the fastboot interface, negating the need to implement the first part of the alpharev hack.
all we need is a modified hboot image.
Check the alpharev page for the 4 choices of partition sizes.
Click to expand...
Click to collapse
Probably not easy as this requires updating fastboot whose source code is not available.
Probably, but seeing as the HW of N1 and Desire is so similar, there is a chance that the code used in the alpharev hack might work, after a little modification to fit the N1.
But then I don't know anything about coding/hacking. I need more input from the dev community.
This requires modification of the bootloader, which wasn't done and requires quite a lot of effort with unknown results. Checking Desire bootloader compatibility might (and probably will) result in a bricked N1, I don't know many people that are willing to take the risk. I know I wouldn't. Without bootloader, repartitioning isn't possible.
Jack_R1 said:
This requires modification of the bootloader, which wasn't done and requires quite a lot of effort with unknown results. Checking Desire bootloader compatibility might (and probably will) result in a bricked N1, I don't know many people that are willing to take the risk. I know I wouldn't. Without bootloader, repartitioning isn't possible.
Click to expand...
Click to collapse
I understand. But what I mean was not flashing the desire bootloader directly to a N1, but using it (or the code base) as a reference for a modified N1 bootloader.
Again, more input is needed from people who have done this kind of thing before.
If i remember correctly,
Firerat has something like this for the G1.
Nobody bothered trying to hack N1 bootloader until now because it has the unlock function built-in - the main reason for reverse-engineering bootloaders isn't there. Bootloader code is binary, no code base there.
Given those facts, the future of bootloader modifications on N1 doesn't look too promising.
I see. Cool.
Thanks for the answers
Good afternoon, my device is supplied by the network 'Three' and from reading previous threads i believe that they are supplied networked locked and that you are unable to unlock the bootloader on this network?. I have two questions;
-Is it possible to see whether a bootloader is unlockable just using the IMEI number? (i see there are various websites, but do any of them actually work)
-If the bootloader is unlockable i am assuming custom roms are out of the question? - However, are there any alternative options?, even just for installing stock or upgrading to 4.1.2?
Thanks in advance!!!!
Paul.
Use revone to unlock or s-off your phone.
You posted in the wrong section.
As I understand it however, you can S-OFF without unlocking the bootloader which allows you to do whatever you want (pretty much).
thank you for prompt replies - apologies if i have posted in wrong forum - I will look into the options you have stated! thanks
This tool has been proven to work with locked bootloaders. I am not sure about the other S-OFF tool's ability to do likewise.
Hi All,
I suppose a really quick question, but before I ask it, I want to say that YES - I have read the threads, YES - I Have done the searches, and because of that, that's why I need to ask - there is so MUCH info, and so many "experts" giving contradicting views/advice that its left me a little confused...
Anyway - I have resisted the urge to do anything non-standard to my One, but the itch is getting too much to not scratch..... now that we have the ability to s-off and change CID and all that good stuff my question is this...
If I root and do all the good stuff, and my phone starts to play up and needs servicing, and although I will have requested my unlock token from HTCdev, with all the tools available to us now, can we, or can we no,t make the phone look and report as totally standard so that it will get a warranty repair?
Thanks
Stokie
revone gets you S-Off without going through HTCDev. And it will get you back to S-On and locked as well.
Q&A for Unlock the Bootloader on Your RAZR i
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for Unlock the Bootloader on Your RAZR i. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
unsupported command
Hello experts,
after having no issues with my Nexus 4 and OnePlus One in terms of fiddling with the booloader/recovery/ROM, I ran into some issues with a friend's Motorola Razr I XT910 (European device for that matter).
Her phone has become so slow, that she's finally willing to give it a go with a non-Motorola ROM.
Following the various guides on the internet, I went to the official Motorola page in order to obtain my unique key to be able to unlock the bootloader to install a custom recovery.
Despeite using the lastest adb.exe and fastboot.exe from the Android SDK, I only got a "unsupported command" when sending my "fastboot oem get_unlock_data".
My understanding was so far that I'll have to perform the usual steps to get a custom ROM on the phone:
open bootloader
install or boot custom recovery
install custom ROM as zip through custom recovery
Do you know this "unsupported command" issue? Is there a workaround I am not aware of?
Best regards
s.i.t.h.l.o.r.d said:
Hello experts,
after having no issues with my Nexus 4 and OnePlus One in terms of fiddling with the booloader/recovery/ROM, I ran into some issues with a friend's Motorola Razr I XT910 (European device for that matter).
Her phone has become so slow, that she's finally willing to give it a go with a non-Motorola ROM.
Following the various guides on the internet, I went to the official Motorola page in order to obtain my unique key to be able to unlock the bootloader to install a custom recovery.
Despeite using the lastest adb.exe and fastboot.exe from the Android SDK, I only got a "unsupported command" when sending my "fastboot oem get_unlock_data".
My understanding was so far that I'll have to perform the usual steps to get a custom ROM on the phone:
open bootloader
install or boot custom recovery
install custom ROM as zip through custom recovery
Do you know this "unsupported command" issue? Is there a workaround I am not aware of?
Best regards
Click to expand...
Click to collapse
The XT910 is just the "Motorola Razr (XT910)" not the "Motorola Razr I (XT890)"
Either way, i don't have a solution, sorry.
Razr i
Would anyone know of a way to unlock the bootloader that motorola says its not available to unlock, obviously its can be done, as someone programed it to do it in the beginning lol
3A25150935255680#54413332343032
4F495600000000000000000000#766E
AE1E67E0D002FA0DEFE8BBA18DB516D
25F15#A214E1C7A097B94A2AB245077
3960000
is my bootloade code...
I looked into using SamDunk for unlocking the bootloader for my AT&T galaxy s5 but noticed that the code posted on the git was Verizon-specific (in that the bits it writes over in the cid of the phone is verizon-specific). This makes it to where running the code does not unlock the bootloader on a AT&T galaxy s5.
I wrote some python code parsing my original cid and the cid resulting from the current exploit code and noticed that the only difference pertained to the product's serial number (bits 47-16 of the cid). Even then, only certain bits within the product serial number are different. I suspect that some bits within product serial pertain to carrier, and some bits pertain to the bootloader, but I could be wrong.
My hunch is that if I can figure out which bits from the original cid's product serial number correspond to developer bootloader access then I may be able to modify the SamDunk code to allow for unlocking AT&T bootloaders. Or provide some method of calculating a dev bootloader cid from an original.
Has anyone else looked into this, and is this worth pursuing?
edit: looking further through SamDunk code. It appears that there is a dev signature associated with the cid (?) that gets written to aboot. Not sure if this is different between phones... If so then experimenting with only the cid may be futile.
product serial numbers are different for the first 12 bits then bits 25-32. I could post a link to my git if anyone is interested in experimenting with their cids
_ibis said:
I looked into using SamDunk for unlocking the bootloader for my AT&T galaxy s5 but noticed that the code posted on the git was Verizon-specific (in that the bits it writes over in the cid of the phone is verizon-specific). This makes it to where running the code does not unlock the bootloader on a AT&T galaxy s5.
I wrote some python code parsing my original cid and the cid resulting from the current exploit code and noticed that the only difference pertained to the product's serial number (bits 47-16 of the cid). Even then, only certain bits within the product serial number are different. I suspect that some bits within product serial pertain to carrier, and some bits pertain to the bootloader, but I could be wrong.
My hunch is that if I can figure out which bits from the original cid's product serial number correspond to developer bootloader access then I may be able to modify the SamDunk code to allow for unlocking AT&T bootloaders. Or provide some method of calculating a dev bootloader cid from an original.
Has anyone else looked into this, and is this worth pursuing?
edit: looking further through SamDunk code. It appears that there is a dev signature associated with the cid (?) that gets written to aboot. Not sure if this is different between phones... If so then experimenting with only the cid may be futile.
product serial numbers are different for the first 12 bits then bits 25-32. I could post a link to my git if anyone is interested in experimenting with their cids
Click to expand...
Click to collapse
I wouldn't mind taking a look.
NavSad said:
I wouldn't mind taking a look.
Click to expand...
Click to collapse
Thanks man, I appreciate all the help I can get.
I read further into the Verizon S5 bootloader unlock thread and it appears that only changing the cid may not work. If I remember correctly (looked at it yesterday) the cid is hashed/compared to the aboot somehow to determine whether its a developer edition or not. If we could get a regular cid/aboot and compare it to the verizon regular cid/aboot, then cross compare to the verizon dev edition cid/aboot then we may have a shot at possibly re-creating a at&t dev edition cid/aboot
_ibis said:
Thanks man, I appreciate all the help I can get.
I read further into the Verizon S5 bootloader unlock thread and it appears that only changing the cid may not work. If I remember correctly (looked at it yesterday) the cid is hashed/compared to the aboot somehow to determine whether its a developer edition or not. If we could get a regular cid/aboot and compare it to the verizon regular cid/aboot, then cross compare to the verizon dev edition cid/aboot then we may have a shot at possibly re-creating a at&t dev edition cid/aboot
Click to expand...
Click to collapse
If the bootloader uses SHA1 it may be easier.
Meanwhile us CID 11s over here just watching you guys from the distance..lol
AptLogic said:
Meanwhile us CID 11s over here just watching you guys from the distance..lol
Click to expand...
Click to collapse
I'm CID 11 too.
NavSad said:
I'm CID 11 too.
Click to expand...
Click to collapse
Oh okay lol.. really wish we could unlock all of the S5 bootloaders instead of just CID 15... what if we try doing like MultiROM with the "no-hardboot" thing like they do on HTC devices? We wouldn't need to patch the Kernel so we'd be able to flash other ROMs.
I know we have Odin mode instead of fastboot and we can not do the "OEM Unlock" in the Developer Options as it does not show up in there. I found this thread (https://www.xda-developers.com/how-to-discover-hidden-fastboot-commands/) on how to discover hidden fastboot commands.
So I followed the instructions there to extract the aboot.img (bootloader) and then "read" the contents of that to see what fastboot commands are available. To my surprise, it has "oem unlock" listed and a few other oem options, see attached image. Although, back to the beginning of my post, we can not fastboot in.
I would assume we could unlock the bootloader via fastboot commands if we only had a way in for it. I am not that experienced with Odin but I think that is only to flash images. I spent most of this weekend searching for any way to alternately try to fastboot in or use Odin but came up with nothing feasible. I used ADB to reboot the phone into all modes and tried doing "fastboot devices" in all modes but it just came back with nothing.
I just wanted to post this in the case of being useful in our attempt to unlock the bootloader.
What do you mean by a way in ?
There is no way, that I know of, to put the s5 in fastboot mode. I was thinking that if there is a way to boot to fastboot, or at least have the phone listed as a fastboot device in ADB, we could possibly run the oem unlock command.
Ok that's what I thought u had meant .... I used to have a few HTC devices I believe was the my touch 4g I'm thinking about ...Anyway some of the roms I had to use ADB and fastboot to flash a kernal sometimes ADB wouldn't pick up device to communicate with fastboot someone had found that by installing PDA.net (I think this was name of app for Windows) it enabled ADB to see the device at any rate .... I no it's a long shot but something to look into if your bored sometime lol I'm not sure why or how it worked or if wouldn't help us at all but I no for a fact it worked on a HTC device so felt was worth mentioning
I'll have a look at that when I get a chance. Anything is worth mentioning as you never know what little piece completes the puzzle!
sorry guys, been out of it for the last two weeks. Projects got crazy but should be able to begin working on this again soon.
I'm fairly certain Thier is still a bounty on this .... I no I pledged 100 bux to whoever unlocks my bootloader and saves me from having to buy a new phone lol but been waiting damn near 4 years not gonna start holding my breath now lol
Towelroot gives kernel memory access, downgrade, use kexec.
This is the easiest way and only one that is guaranteed to work since all exploits have already been made.
Guicrith said:
Towelroot gives kernel memory access, downgrade, use kexec.
This is the easiest way and only one that is guaranteed to work since all exploits have already been made.
Click to expand...
Click to collapse
If, of course, we could get kexec to WORK. Any modification of the Kernel breaks the chain of trust and the phone goes into a bootloop.
We dont need to modify the kernel, TowelRoot would write kexec from a file(/system/userlandbootloader.img) into the kernel after boot, then the kernel would boot a new kernel from /system/oskernel.img (which is writable on rooted 4.4-5.0)
The only kernel being modified is the one running in ram and that is deleted and replaced every reboot so trust chain is never broken.
Guicrith said:
We dont need to modify the kernel, TowelRoot would write kexec from a file into the kernel after boot, then the kernel would boot a new kernel from /system/oskernel.img (which is writable on rooted 4.4-5.0)
The only kernel being mdifyed is the one running in ram and that is deleted and replaced every reboot so trust chain is never broken.
Click to expand...
Click to collapse
But for everything to work correctly we need to be able to hardboot to the new kernel, so we need to patch the existing one to support it.
Why?
If you have kernel access you can just set all values to there boot time default.(unless there is hardware locked values like the gameboy color bootloader)
Clear the mmu mappings.
memset((void*)0x00000000, 0x00, sizeof(systemram));
Now it is in a pre boot state.
If that does not work triggering a crash that does not reload the kernel from rom but hardboots the system may work too.
Guicrith said:
Why?
If you have kernel access you can just set all values to there boot time default.(unless there is hardware locked values like the gameboy color bootloader)
Clear the mmu mappings.
memset((void*)0x00000000, 0x00, sizeof(systemram));
Now it is in a pre boot state.
If that does not work triggering a crash that does not reload the kernel from rom but hardboots the system may work too.
Click to expand...
Click to collapse
If we can code this and get consistent successful results we'd basically have a workaround for most locked BL devices to boot a custom ROM.
Of course the only theoretical hurdle left would be to actually code something like this.