Related
Has any one so far managed to unlock the bootloader and root the retail version of the tab. I'm asking cuz a friend is looking to get the retail version but won't get it unless its unlockable and root -able. Does pressing the vol down and power take you to recovery?
I know the io version has been rooted.
Sent from my GT-P7100 using XDA App
I am able to get into Recovery fine. Unfortunately there is no mounted sdcard, so although I can push with ADB, I cannot actually load the zip.
Just mount the file create the directory and place files there
Mount the ZIP?
Could someone please post exact instructions how to apply these zip files? As previously noted, we do not have access to the sdcard when booting into recovery. Thanks!
Yes please tell us how to mount /sdcard/
I have the retail version from Best Buy and /sdcard is not mounted. I tried to mount it but I don't seem to be able to. Also when I try to run fastboot devices it comes up blank but adb devices returns:
D:\android-sdk-windows\tools>adb devices
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached
37C7046403FF217 device
I also tried in Ubuntu and same result... adb communication working, but fastboot executable can't see the device and I don't know how to get the /sdcard mounted using adb.
*** Please help ***
Please check the development forum. I bought mine from BestBuy on Friday, 16G metallic one. It is rooted.
The basic steps are to use nvflash to replace the stock bootloader with one that was from Googles IO tabs, then installing CWM, then rooting. Took me about 20 minutes.
xavierdylan said:
Has any one so far managed to unlock the bootloader and root the retail version of the tab. I'm asking cuz a friend is looking to get the retail version but won't get it unless its unlockable and root -able. Does pressing the vol down and power take you to recovery?
I know the io version has been rooted.
Sent from my GT-P7100 using XDA App
Click to expand...
Click to collapse
The threads you need are:
Retail 3.1 CWM - http://forum.xda-developers.com/showthread.php?t=1130574
If you use the above thread, then refer to this thread when you get to the "root like you have an i/o tab now" part of the instructions - http://forum.xda-developers.com/showthread.php?t=1074802
If your bootloader is locked (No padlock icon appears when you boot) http://forum.xda-developers.com/showthread.php?t=1131448
Sandelb said:
The threads you need are:
Retail 3.1 CWM - http://forum.xda-developers.com/showthread.php?t=1130574
If you use the above thread, then refer to this thread when you get to the "root like you have an i/o tab now" part of the instructions - http://forum.xda-developers.com/showthread.php?t=1074802
If your bootloader is locked (No padlock icon appears when you boot) http://forum.xda-developers.com/showthread.php?t=1131448
Click to expand...
Click to collapse
The above links worked for me. I have a 16GB Tab purchased from Best Buy.
On initial bootup I had the unlocked icon on the boot screen so I don't know if the same method works for tabs without the unlocked icon.
But here is something very important. The Samsung USB drivers for PCs are a mess. There are so many versions for different devices (I have had 7 other Samsung devices that all connect to my PC via USB) After having constant connection problems I realized that the simple solution was to go to a "clean" PC (one that had never had Samsung USB drivers installed) and install nvflash per the instructions. Without the legacy Samsung USB drivers the nvflash method worked flawlessly.
Hello
Is there any chance of unlocking the locked bootloader for the SGT ??
guys I dont think I have seen any recent posts by anyone claiming theirs is locked. I have a locked white 16gb that I had got at the launch on the 8th but I am pretty sure most if not all of the tabs are unlocked at stores.
If someone can show a post indicating the user got it sometime between the 17th and now and it being locked, please indicate so
Some still locked...
Had a launch unit that was locked. Returned it for the metallic one on the 20th and wound up with another locked one.
Rooted using the above linked instructions though, worked like a charm.
NyPlaya513 said:
guys I dont think I have seen any recent posts by anyone claiming theirs is locked. I have a locked white 16gb that I had got at the launch on the 8th but I am pretty sure most if not all of the tabs are unlocked at stores.
If someone can show a post indicating the user got it sometime between the 17th and now and it being locked, please indicate so
Click to expand...
Click to collapse
I got mine on the launch from Best Buy and it was locked. 16GB metallic WiFi model.
So basically whether you get a locked or unlocked bootloader is a free for all?
What gives Samsung...
Could they potentially release an update unlocking the bootloader for everyone?
meeekael said:
So basically whether you get a locked or unlocked bootloader is a free for all?
What gives Samsung...
Could they potentially release an update unlocking the bootloader for everyone?
Click to expand...
Click to collapse
From what I've been hearing you're just lucky. There are some that are unlocked but the majority are locked. I doubt Samsung will be releasing anything to help but, I'd keep up in the forums, someone smarter than us will fix the issue for them!
Retail Roulette?
So, I've been kind of interested in this and, since I work at Best Buy's Geek Squad I've got a chance to check out the SGT's that get returned. It really does seem kind of random. I've seen 3 so far, 2 16GB's and 1 32GB returned since launch. The 32GB was unlocked as was one of the 16's. So, I don't know what the deal is... perhaps poor QC at Samsung manufacturing? Got me, LoL!
Hey there,
I have a few questions for owners of the Nexus 7 or anyone who is able to help me
1. When you fastboot oem unlock to unlock the bootloader, does the device get wiped? I ask because someone mentioned that the Galaxy Nexus from the play store no longer wipes when running that command.
2. When you unlock the bootloader, do you no longer receive OTA updates? and if not, does it just require a simple relock to get back in the update channel? This is mainly for my N7 but also as I recently sold my friend a Galaxy Nexus which I relocked the bootloader too, and I hope he can still get OTA updates for Jelly Bean and the likes.
Any help would be greatly appreciated,
Thanks in advance,
DarkRyoushii
Not sure on number one.
Number two is bootloader state has no effect on ota's
Thanks for the reply. I'm still really curious about the first question though. It would be great if it's the same as the play store nexus because then I won't be pressured to unlock the device when I first get it
Sent from my GT-I9300 using xda app-developers app
I unlocked mine before setup. So I don't know if it wiped anything.
Sent from my Nexus 7 using Tapatalk 2
is "unlocking the bootloader" another word for rooting then? Google results seem to suggest that when I looked up the term. "Unlocking the boot loader allows you to put custom ROMs on your phone" - from a Sonymobile Xperia site.
Salty Wagyu said:
is "unlocking the bootloader" another word for rooting then?
Click to expand...
Click to collapse
It's essentially step one of that process.
"Unlocking the Bootloader" is entirely different than "Rooting", although it is a prerequisite.
The Unlock operation will warn you that it will wipe the device - if it still does.
Anyone who unlocks should be able to tell us if they get that warning.
Unlocking the boot loader will wipe your device:
http://forum.xda-developers.com/showthread.php?p=28267712
'Note: You need to unlock the bootloader in order to use this Superboot. Note that the OEM unlock sequence wipes your device'
Sent from my HTC One X using Tapatalk 2
quick linux/android primer
A bootloader is a small program which directly interfaces with the hardware to load a secondary program. That secondary program can be either a second stage to a bootloader or the actual OS, in this case, android. An OEM locked bootloader will only load a secondary program which is approved by the OEM. It usually does this by signing the code with a digital signature. Unlocking the bootloader will allow unsigned code to be executed. This unsigned code can be Another ROM or an altered version of the existing ROM.
Rooting is the process of obtaining superuser access to the operating system, in this case, android. In Linux and android, the superuser is the only user which can execute certain programs or write to protected filesystems such as /system. It is desirable to have root access to the OS so that you can perform extra functions such as hardware configuration like overclocking the CPU speed.
Without an unlocked bootloader, you can not run the program required to gain root access. As well, you must gain permanent root so you don't lose access when the device reboots.
Hope this clears it up for you.
DarkRyoushii said:
Hey there,
I have a few questions for owners of the Nexus 7 or anyone who is able to help me
1. When you fastboot oem unlock to unlock the bootloader, does the device get wiped? I ask because someone mentioned that the Galaxy Nexus from the play store no longer wipes when running that command.
2. When you unlock the bootloader, do you no longer receive OTA updates? and if not, does it just require a simple relock to get back in the update channel? This is mainly for my N7 but also as I recently sold my friend a Galaxy Nexus which I relocked the bootloader too, and I hope he can still get OTA updates for Jelly Bean and the likes.
Any help would be greatly appreciated,
Thanks in advance,
DarkRyoushii
Click to expand...
Click to collapse
1. Yes, unlocking the bootloader does wipe your device.
2. Unlocking the bootloader and rooting "per se" doesn't prevent you from receiving any OTA updates (thanks albundy2010 for the clarification on this).
Just having root doesn't effect ota either
albundy2010 said:
Just having root doesn't effect ota either
Click to expand...
Click to collapse
You mean on the Nexus 7 or in general ? Because I've never been able to receive OTA updates in my phones while rooted.
Any nexus device for sure and just about every device that I know off.
Stock rooted roms will not have a issue with a ota. The issues come from custom roms?/ changes in /system that the updater script checks for etc.
Think about it for a second. All the I installed the update and lost root! How can I fix it topics. Ota root keepers and so on.
Root alone does not stop ota's. It is what the user ends up doing with root access that does
albundy2010 said:
Any nexus device for sure and just about every device that I know off.
Stock rooted roms will not have a issue with a ota. The issues come from custom roms?/ changes in /system that the updater script checks for etc.
Think about it for a second. All the I installed the update and lost root! How can I fix it topics. Ota root keepers and so on.
Root alone does not stop ota's. It is what the user ends up doing with root access that does
Click to expand...
Click to collapse
You're absolutely right, mate. I totally forgot about the fact I have custom roms in all my Nexus phones, hence my confusion.
Nexus 7 unlock bootloader problem
Hey guys,
I'm having issues unlocking the bootloader on my Nexus 7. I've followed instructions that I've seen all over the web. I have the latest SDK and google usb driver and USB debugging is enabled. I've rebooted both my PC and Nexus 7 with no success in running "fastboot oem unlock" which stays on "waiting on device." I did run "adb devices" and it lists my Nexus 7 by its serial number. Any help would be greatly appreciated.
rmm200 said:
"Unlocking the Bootloader" is entirely different than "Rooting", although it is a prerequisite.
The Unlock operation will warn you that it will wipe the device - if it still does.
Anyone who unlocks should be able to tell us if they get that warning.
Click to expand...
Click to collapse
How was the nook tablet rooted before the uboot exploit was discovered? Trying to understand more about these things.
Sent from my Nook Tablet using xda app-developers app
Unlocking the bootloader erases the userdata & cache. Here's what I got on command line:
E:\downloads\Android\androidsdk\platform-tools>.\fastboot oem unlock
...
(bootloader) erasing userdata...
(bootloader) erasing userdata done
(bootloader) erasing cache...
(bootloader) erasing cache done
(bootloader) unlocking...
(bootloader) Bootloader is unlocked now.
OKAY [ 66.329s]
finished. total time: 66.331s
Guys,
We've seen several people have flashed system.img's and OTA's and ended up in a bootloop.. Not the end of the world really, BUT for some reason, before you can unlock your bootloader using fastboot, you must enable OEM unlock in Developer options in Android settings - which you cannot do if you are bootlooping.
If you still have a custom recovery, you'll be fine but if you're 100%, locked bootloader and bootlooping, we haven't found a fix yet so please do not lock your bootloader.
If you feel you absolutely must relock your bootloader (at your own risk) please boot the phone up to check it works properly before doing this. If you intend flashing roms and kernels or custom recoveries, locking the bootloader is not a good idea
Please also see the below link provided by @efrant
https://support.google.com/nexus/answer/6172890?hl=en
This goes into more detail about how google have enhanced device security with 5.1 and some other pitfalls that you may wish to avoid. This is pretty salient information, so do give it a read.
Good advice, i would add to that NEVER LOCK YOUR BOOTLOADER. ???
Sent from my Nexus 9 using XDA Free mobile app
ChristianJay said:
Good advice, i would add to that NEVER LOCK YOUR BOOTLOADER.
Sent from my Nexus 9 using XDA Free mobile app
Click to expand...
Click to collapse
And I would add that I completely disagree with this statement. Coming from an infosec standpoint, I keep my bootloader locked, and just suffer the reset when I need to tweak. If you don't, anyone - not just you - can replace your system partition or boot a random IMG which could inject functionality. This may not be the most common mechanism for attack as it requires physical access, but it basically obviates the encryption with a deepfreeze style boot IMG.
Additionally, when you think about this in context of the border crossing exemptions many countries, including the US, have to protections against unwarranted search, I would recommend that anyone with proprietary or sensitive business data who crosses international borders keeps their bootloader locked when not modifying the system. Also, until custom recoveries include security features, I recommend using stock.
Why are we making our phones so insecure just to have root? Not cool.
So just to be clear the correct procedure would be to boot the device after updating enable the setting and then go and lock your bootloader? Or just keep it unlocked overall.
Personally I keep mine unlocked but for those wanting to take full advantage of androids new device protection a locked bootloader would serve a purpose. Preventing someone from just flashing a custom rom and keeping your device.
:thumbup:
I thought I really #$# up
Thank you for posting this...when 5.1 was dropping, I attempted to return to stock...all the way.to be able to take Verizon's OTA...when i locked the boot loader, i was stuck in a boot loop with the android guy and the gear box spinning FOREVER.....its is not easy to get out of the loop, but i managed to boot back up into boot loader mode, and force a stock image using toolkit.
I am now unlocked, running 5.1 on Verizon, have full LTE/VOLTE, can speak and surf at same time...i have not rooted yet...but just glad it was not me....had a heart attack two nights ago...
xander45 said:
Thank you for posting this...when 5.1 was dropping, I attempted to return to stock...all the way.to be able to take Verizon's OTA...when i locked the boot loader, i was stuck in a boot loop with the android guy and the gear box spinning FOREVER.....its is not easy to get out of the loop, but i managed to boot back up into boot loader mode, and force a stock image using toolkit.
I am now unlocked, running 5.1 on Verizon, have full LTE/VOLTE, can speak and surf at same time...i have not rooted yet...but just glad it was not me....had a heart attack two nights ago...
Click to expand...
Click to collapse
im so new to this but im rooted with an unlocked bootloader but im running full stock android. i only rooted just so i can chance the provision to get free tethering with my unlimited data. i have the wugfresh nexus tool kit and cant for the life of me figure out how to upgrade my nexus 6 to 5.1. Is there in anyone that can get me a step by step on how to update so i can take advantage of hd calling and silmutaneous voice and data... ive been waiting tooooooooooo long for this update..
rootSU said:
Guys,
We've seen several people have flashed system.img's and OTA's and ended up in a bootloop.. Not the end of the world really, BUT for some reason, before you can unlock your bootloader using fastboot, you must enable OEM unlock in Developer options in Android settings - which you cannot do if you are bootlooping.
If you still have a custom recovery, you'll be fine but if you're 100%, locked bootloader and bootlooping, we haven't found a fix yet so please do not lock your bootloader.
Click to expand...
Click to collapse
Hi root,
I saw that thread yesterday ...
I thought this was already covered when the N6 came out, to get the bootloader unlocked you had to do a 1st boot of the device and ENABLE OEM Unlock, then you were good to go to get into fastboot and unlock.
The reason was google put the option there for 5.0, vice all our previous versions which had no toggle for it.
I think it was people jumping the gun and not doing that first boot, but immediately jumping into fastboot and flashing, and that caused it, yes? Because the BL wasn't unlocked, they couldn't flash the OTA and boot img ...
daijizai said:
And I would add that I completely disagree with this statement. Coming from an infosec standpoint, I keep my bootloader locked, and just suffer the reset when I need to tweak. If you don't, anyone - not just you - can replace your system partition or boot a random IMG which could inject functionality. This may not be the most common mechanism for attack as it requires physical access, but it basically obviates the encryption with a deepfreeze style boot IMG.
Additionally, when you think about this in context of the border crossing exemptions many countries, including the US, have to protections against unwarranted search, I would recommend that anyone with proprietary or sensitive business data who crosses international borders keeps their bootloader locked when not modifying the system. Also, until custom recoveries include security features, I recommend using stock.
Why are we making our phones so insecure just to have root? Not cool.
Click to expand...
Click to collapse
This is nonsense.
You need *physical* access to it in order to carry out such an attack.
If your phone leaves your PHYSICAL access, then you already know not to trust what is on it, whether or not it has an unlocked bootloader.
xander45 said:
Thank you for posting this...when 5.1 was dropping, I attempted to return to stock...all the way.to be able to take Verizon's OTA...when i locked the boot loader, i was stuck in a boot loop with the android guy and the gear box spinning FOREVER.....its is not easy to get out of the loop, but i managed to boot back up into boot loader mode, and force a stock image using toolkit.
I am now unlocked, running 5.1 on Verizon, have full LTE/VOLTE, can speak and surf at same time...i have not rooted yet...but just glad it was not me....had a heart attack two nights ago...
Click to expand...
Click to collapse
kng60ft said:
im so new to this but im rooted with an unlocked bootloader but im running full stock android. i only rooted just so i can chance the provision to get free tethering with my unlimited data. i have the wugfresh nexus tool kit and cant for the life of me figure out how to upgrade my nexus 6 to 5.1. Is there in anyone that can get me a step by step on how to update so i can take advantage of hd calling and silmutaneous voice and data... ive been waiting tooooooooooo long for this update..
Click to expand...
Click to collapse
There is no need to lock the device to take an OTA. You can keep it unlocked and do an ota
doitright said:
This is nonsense.
You need *physical* access to it in order to carry out such an attack.
If your phone leaves your PHYSICAL access, then you already know not to trust what is on it, whether or not it has an unlocked bootloader.
Click to expand...
Click to collapse
Not nonsense. Yes you need physical access to carry out the attack, but with a locked bootloader and the new precautions against unlocking and fastboot it makes locked bootloaders fairly bulletproof.
I cannot recommend unlocked bootloaders to anyone that works SCIF'd and leaves their phone in a shared box during the day, anyone that crosses international borders, or anyone whose phone might contain IP or trade secrets and could be a target of theft.
This is as much about trusting the phone afterwards as it is about protecting your data on the phone - even when encrypted.
y2whisper said:
So just to be clear the correct procedure would be to boot the device after updating enable the setting and then go and lock your bootloader? Or just keep it unlocked overall.
Personally I keep mine unlocked but for those wanting to take full advantage of androids new device detection a locked bootloader would serve a purpose.
Click to expand...
Click to collapse
Just keep it unlocked
rootSU said:
Guys,
We've seen several people have flashed system.img's and OTA's and ended up in a bootloop.. Not the end of the world really, BUT for some reason, before you can unlock your bootloader using fastboot, you must enable OEM unlock in Developer options in Android settings - which you cannot do if you are bootlooping.
If you still have a custom recovery, you'll be fine but if you're 100%, locked bootloader and bootlooping, we haven't found a fix yet so please do not lock your bootloader.
If you feel you absolutely must relock your bootloader (at your own risk) please boot the phone up to check it works properly before doing this. If you intend flashing roms and kernels or custom recoveries, locking the bootlaoder is not a good idea
Click to expand...
Click to collapse
I had this boot loop also, but clearing Cache and Dalvik seemed to fix the loop for me.
nyteryder79 said:
I had this boot loop also, but clearing Cache and Dalvik seemed to fix the loop for me.
Click to expand...
Click to collapse
Thats good.
http://forum.xda-developers.com/goo...orial-how-to-flash-factory-images-lg-t2713833
This may help if you got stuck in a bootloop.
is there a fix if my mem shows i own a 32g device when i bought a 64g device, im unlocked/rooted and on custom rom?
darren.wlsn1 said:
is there a fix if my mem shows i own a 32g device when i bought a 64g device, im unlocked/rooted and on custom rom?
Click to expand...
Click to collapse
I'd like to know too. I'm unrooted, stock everything, with 64GB Blue, but it shows 23GB total space for the device with 16GB available. Was fine before the 5.1 update.
Marcellus1 said:
I'd like to know too. I'm unrooted, stock everything, with 64GB Blue, but it shows 23GB total space for the device with 16GB available. Was fine before the 5.1 update.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=58201783&postcount=106
should help
darren.wlsn1 said:
is there a fix if my mem shows i own a 32g device when i bought a 64g device, im unlocked/rooted and on custom rom?
Click to expand...
Click to collapse
Marcellus1 said:
I'd like to know too. I'm unrooted, stock everything, with 64GB Blue, but it shows 23GB total space for the device with 16GB available. Was fine before the 5.1 update.
Click to expand...
Click to collapse
Factory reset?
Not really the thread to ask this though.
rootSU said:
Factory reset?
Not really the thread to ask this though.
Click to expand...
Click to collapse
Thanks, and sorry
The new Device Protection features of Android 5.1 on the Nexus 9 and Nexus 6 can, in certain cases, cause you to have a bootloader which can not be unlocked.
Please have a read of the following links:
https://support.google.com/nexus/answer/6172890?hl=en
http://forum.xda-developers.com/nexus-6/help/update-to-5-1-lock-bootloader-t3058480
http://forum.xda-developers.com/nexus-6/general/relock-bootloader-time-updating-to-5-1-t3053497
What a pita
Sent from my Nexus 5 using XDA Free mobile app
i would never relock my bootloader
people unlock there bootloader for a reason
but to relock it after thats just wrong...
thats one of the things i hate about CM
they recommend you to relock your bootloader...
Agreed, why would you lock your bootloader unless sending in for repairs maybe?
But Google is really messing up the flow. The nexus 6 5.1 OTA is a mess right now but I will leave that for another thread.
Android 5.1 for Nexus 9? You must be joking.
So, I just purchased a Nexus 9 via the 4-hour online-only sale at Best Buy. It was $100 off, couldn't pass it up. My question is: is this likely going to be shipped in such a condition as to prevent me from permanently unlocking the bootloader? Or is a permanent lock something one must deliberately do?
disturbd1 said:
So, I just purchased a Nexus 9 via the 4-hour online-only sale at Best Buy. It was $100 off, couldn't pass it up. My question is: is this likely going to be shipped in such a condition as to prevent me from permanently unlocking the bootloader? Or is a permanent lock something one must deliberately do?
Click to expand...
Click to collapse
No no you can still unlock it
But if you relock it that's the problem
disturbd1 said:
So, I just purchased a Nexus 9 via the 4-hour online-only sale at Best Buy. It was $100 off, couldn't pass it up. My question is: is this likely going to be shipped in such a condition as to prevent me from permanently unlocking the bootloader? Or is a permanent lock something one must deliberately do?
Click to expand...
Click to collapse
As USBhost said, you'll be able to unlock it. However, when you are first setting it up and are running through the set-up wizard, there will be an option to "Protect Device" or something like that. If you enable it, and re-lock the bootloader, it will put you in a situation where you can only unlock the booloader in certain situations -- and if you happen to have a bootloop with a locked bootloader, that's when you are in trouble.
EDIT: On Nexus devices, I personally unlock the bootloader as soon as I take it out of the box, without first booting into Android, and then leave it unlocked. But of course, you give up some security by doing that.
efrant said:
As USBhost said, you'll be able to unlock it. However, when you are first setting it up and are running through the set-up wizard, there will be an option to "Protect Device" or something like that. If you enable it, and re-lock the bootloader, it will put you in a situation where you can only unlock the booloader in certain situations -- and if you happen to have a bootloop with a locked bootloader, that's when you are in trouble.
EDIT: On Nexus devices, I personally unlock the bootloader as soon as I take it out of the box, without first booting into Android, and then leave it unlocked. But of course, you give up some security by doing that.
Click to expand...
Click to collapse
Considering this is a tablet, hopefully I won't lose or misplace it
Thanks, guys! Glad I stumbled across this thread before the thing arrived.
Locking the bootloader doesn't protect you from anything. If the device leaves your physical control in a potentially hostile environment, whatever is on the system or boot partition becomes suspect, regardless of whether the bootloader is locked or unlocked.
doitright said:
Locking the bootloader doesn't protect you from anything. If the device leaves your physical control in a potentially hostile environment, whatever is on the system or boot partition becomes suspect, regardless of whether the bootloader is locked or unlocked.
Click to expand...
Click to collapse
Example: I have a device running a stock ROM with no encryption, the stock recovery and a lock screen password. I happen to lose my phone. What happens to the photos of me dancing to Old Time Rock & Roll in my underwear that are stored on the device? If the bootloader is unlocked, someone just plugs it into a PC, boots TWRP and pulls them off. If the bootloader is locked, there is no easy way to see or get the photos off the device.
That is all I was saying about security. Nothing to do with you leaving your device somewhere or losing it, and then finding it again. Strictly about the personal content on the device.
efrant said:
EDIT: On Nexus devices, I personally unlock the bootloader as soon as I take it out of the box, without first booting into Android, and then leave it unlocked. But of course, you give up some security by doing that.
Click to expand...
Click to collapse
I thought Lollipop always requires you to go in and check the Enable OEM Unlock box? Or is that not true if you never booted into Android even once?
bailyc said:
I thought Lollipop always requires you to go in and check the Enable OEM Unlock box? Or is that not true if you never booted into Android even once?
Click to expand...
Click to collapse
If you have never booted into Android, then you don't need to check that setting. As I said, that's the way I did it on my N6: take out of box -> charge -> boot directly into bootloader -> "fastboot oem unlock". No other steps required if you don't boot into Android first.
can i use this guide for safely relock my Bl on Nexus 9 ..... Relocking coz of RMA and warranty purpose as bought from amazon India instead of Play Store
http://forum.xda-developers.com/nexus-6/general/guide-safely-lock-bootloader-android-5-1-t3067302
lilliput222 said:
can i use this guide for safely relock my Bl on Nexus 9 ..... Relocking coz of RMA and warranty purpose as bought from amazon India instead of Play Store
http://forum.xda-developers.com/nexus-6/general/guide-safely-lock-bootloader-android-5-1-t3067302
Click to expand...
Click to collapse
Yes, that should work for the N9 as well.
The bootloader on my Nexus 9 Android 5.1.1 is locked forever due to my mistake
Short backstory:
- I wanted to install the Android M developer Preview for the Nexus 9 but I forgot to check "Enable OEM unlock" in developer options (worst mistake).
- I used adb command to flash the new image but failed somehow
- I carelessly type # fastboot oem lock
- I tried to factory reset from bootloader to bring it back to Stock. Now it couldn't factory reset and my Nexus 9 hangs in a nice boot loop.
- I try # fastboot oem unlock but failed with permission denied error
I tried some ways to save my device but no hopes
- I used Nexus Root Tookit to unlock bootloader or restore image with force mode but failed,
- I follow instruction in HTC dev forum to get identifier token in order to receive your unlock code binary file but failed
- Unluckily, I don't installed any custom recovery.
Please help if you know a way unlock the bootloader or flash the factory ROM to save the nexus 9
quekl84 said:
Please help if you know a way unlock the bootloader or flash the factory ROM to save the nexus 9
Click to expand...
Click to collapse
Not possible. You will have to return it to HTC for repair or replacement.
quekl84 said:
Short backstory:
- I wanted to install the Android M developer Preview for the Nexus 9 but I forgot to uncheck "Enable OEM unlock" in developer options (worst mistake).
- I used adb command to flash the new image but failed somehow
- I carelessly type # fastboot oem lock
- I tried to factory reset from bootloader to bring it back to Stock. Now it couldn't factory reset and my Nexus 9 hangs in a nice boot loop.
- I try # fastboot oem unlock but failed with permission denied error
I tried some ways to save my device but no hopes
- I used Nexus Root Tookit to unlock bootloader or restore image with force mode but failed,
- I follow instruction in HTC dev forum to get identifier token in order to receive your unlock code binary file but failed
- Unluckily, I don't installed any custom recovery.
Please help if you know a way unlock the bootloader or flash the factory ROM to save the nexus 9
Click to expand...
Click to collapse
u mean u forgot to CHECK to box to allow oem UNLOCK? im confused lol
cobyman7035 said:
u mean u forgot to CHECK to box to allow oem UNLOCK? im confused lol
Click to expand...
Click to collapse
Yes, I forgot to check the box to allow oem UNLOCK. And now my device is locked forever.
A quick question: A lot of N9 ROMs require flashing an updated bootloader from the factory image. Aren't these bootloaders locked by default? Can we flash a factory bootloader over a custom ROM?
It seems that we might bork our Nexus 9s if we flash a locked bootloader in.
I know that the Verizon bootloader is almost impenetrable as is, but would it be plausible to completely go over the head of the firmware and directly write an image with JTAG that would allow for custom software? If so, would it be possible to use the firmware from another carrier like USC or would it have to be a custom image?
EDIT: summary of the method and everything I have thusfar discovered
So, this method after a bit of evolution, got to the point it basically entailed the following: Using the SD Card debrick method (popularized by the galaxy s3 LTE variants) a modified firmware image would be written to an SD Card, and the phone would boot from that image. The main problem I ran into: it would not let me flash anything that could brick the phone, nor was I able to pull the usb cord at the right moment and try and manually brick it. I was able to flash firmware and stock tars from other variants of the phone (such as the one that runs on T-mobile), but what I found out through that is a couple things:
1. The stock tars seem mostly carrier independent, and I was without any modification able to flash a T-mobile bootloader, system image, and pit file, but within recovery and download mode it would show that because of integrated CSC, it would still change back to the original variant. This could have implications for a very simple method of removing bloat from the phone, but I'm not so sure
2. It must have a very low level method of injecting information and file verification that is not located anywhere on eMMC
The latter led me to research a TON, eventually finding that the most likely culprit is the use of Qualcomm Qfuses, non-volatile pre-set memory located directly on the SoC, to check how the bootloader is signed. They consist of a couple blocks of registers, and definitely aren't readily writable. The trusted base of the entire secure system, the same system that KNOX invokes on other systems, is within a series of Qfuses. From what I have deduced, however, they must be at some software level writable, as although the Knox counter is an e-fuse, the others (such as the warrantee bit) have been both changed upon their void and reverted when brought back to a service center. This must mean that the entire block is possible to modify in both directions, unlike a fuse or breaker; It seems to act more like flash memory than a "fuse." This is very good, mainly because if the service center can change it it means that jtag has not been disabled by those flags, and is enabled in at least some form. What this also means is that without another MAJOR exploit within unfortunately simple, clean code or a leak of several RSA keys from verizon, either current workarounds such as safestrap are the answer for the foreseeable future, or a method of manually changing a simgle Qfuse (the one that controls the "Qualcomm Secureboot" flag) could be used.
What I'm hopefully going to start at some point here is research into finding a way of accessing and changing that Qfuse via JTAG. I have no money for a JTAG box at the moment, so it'll have to wait, but if anyone who already has one wants to use it, hopefully this info helps
P.S. I figured out exactly what T-flash does in odin: it flashes the files that you input into odin to the currently inserted SD Card (or so it seems, I could be wrong but that's what it did for me)
P.P.S. Verizon, I respectfully request that...oh never mind, profanity is definitely frowned upon here
Also, I'm in ongoing discussion with the FCC as to block C violations by Verizon of aspects of the regulations that upon research have not really been argued to any substantial extent, so if that comes to fruition hopefully there'll be simple ODIN flashable patches for this stuff :fingers-crossed:
UPON REFLECTION: if the phone could be bricked, either by very subtly corrupted file or by interrupting a flash at the right moment, then could the debrick image from a tmobile galaxy s5 with an unlocked bootloader be used as not a method of flashing the on-board bootloader but as a kind of external boot, so a permenantly installed SD Card that would be permissive of modified kernels and such but still accepted as a boot device by the phone?
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
tr4nqui1i7y said:
I was wondering something similar. It would be interesting to see if we could do something similar to what we did for the droid x.
Click to expand...
Click to collapse
what was done with the droix x? Did they use a direct JTAG patch?
I just realized something. From reading here: http://forum.gsmhosting.com/vbb/f200/how-fix-samsung-galaxy-s5-sm-g900f-dead-boot-1813266/
It seems to show that the S5 has a "alternative boot upon init fault" method similar to that that allows the galaxy s3 debrick to work (I have a guide I made with details) so would it be possible to somehow corrupt a very important part of the bootloader in an official update (would one or two bits still mess with the signature?), apply that, and have an insecure bootloader on a microsd card in the phone allowing it to boot into that, then use that with odin to flash an insecure bootloader to the s5 itself?
Now I have to ask an interesting question somewhere (since he: http://forum.xda-developers.com/verizon-galaxy-s5/help/g900v-hard-brick-t2914847 seems to have done it): "guys how do I brick my sm-g900v?"
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
tr4nqui1i7y said:
They hijacked the boot init by basically using an alternate boot. It was essentially telling the phone to use a different boot method.
Check out koushs bootstrapper for the droid x and droid 2
Koush, birdman, and apex were the three that I remember the most from the beginning. When I remember who got root first, I'll post here. That or I'll try to get in touch with them.
Click to expand...
Click to collapse
I think it might actually be easier
So long as a couple conditions are met for it:
1. The bootloader alone determines if an image is "signed" or not (like when flashed in odin)
2. The same UnBrick exploit from the S3 LTE variants works in some form (secondary storage, fault-triggered boot)
3. It is possible to get it to load a modified bootloader from that secondary boot (this is why number 1 is important)
4. KNOX is completely firmware based, and doesn't have any chip based verification
5. I or someone else actually knows how to modify the bootloader such that it will allow unsigned images (even if not removing it all together, then changing the key to one they publicize so people can sign their rom with it)
If all of these are met, then we might actually have free root! Basically all it would involve would be bricking the device badly enough it boots from secondary storage, have that secondary boot have a "back door" that allows a custom image to be flashed, that allows a bootloader image to be flashed that allows for a signed recovery (signed with that publicly available code) to be flashed without having to deal with safestrap or anything like that. Just full root like on any other phone. Anyone want to offer an opinion? Will this work? I would love to try this out, though I'm a bit unwilling to offer my s5 as a sacrifice just yet as I don't have a JTAG unit on site. I know the bounty is probs gone but I'm ok just getting my bootloader unlocked an' $#*+
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
tr4nqui1i7y said:
The bootloader doesn't need to be bricked, it just needs to be bypassed. If we can find the magic words then we'll be golden.
I'm researching tonight. I'll try tests, hopefully tomorrow. Not sure when I'll be able to have the tone for sure.
An unlock isn't likely. A bypass should be possible though.
Click to expand...
Click to collapse
Have you found anything yet?
dreamwave said:
Bypassed in what way? I understand the thing with safestrap and such, but that doesn't allow custom kernels or anything, so just modified tw roms which is kinda limiting
Click to expand...
Click to collapse
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
dreamwave said:
safestrap uses root access in a stock rom to create a temporary recovery image that lasts for one boot, but it can be finicky and no way to boot into it if you can't access the rom
Click to expand...
Click to collapse
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
tr4nqui1i7y said:
I need to look up this "safestrap" thing. It sounds like it might be the same thing. Also, by no means does any of this mean root access. If safestrap is what it sounds like, then the concept I was attempting might have already been done.
Safestrap appears to be the same concept, applied in a different way. I've got to do some catching up. I just got the s5, so I'm very late to the show. I'm wondering if anyone has looked into the similarities between the s5 variants.
Click to expand...
Click to collapse
that's why I'm hoping the debrick image method will work
tr4nqui1i7y said:
The Droid X bootstrap was used with the same intent. It didn't allow custom kernels either. It didn't allow pure aosp ROMs because of that. It modified a boot file to boot to the custom ROM, rather than the actual ROM. It wasn't a recovery or anything like that. It was in app form and only needed to be applied manually the initial time. Unless you wanted to switch/update your custom ROM.
I'm wondering if safestrap, in conjunction with the oe1 rooted build, the oe1 tar, and the boot vulnerability could lead to a method that would allow a one time "downgrade".
Something along the lines of applying a pre-rooted tar, leaving the phone in a bricked state since the bootloader can't be downgraded, adb pushing safestrap files into place, thus modifying the bootloader to get passed the bricked state, allowing it to boot into the rooted tar that was applied or even booting into a ROM possibly.
^ Is all an uneducated guess. I haven't done enough research to know how viable of an option that would be.
Click to expand...
Click to collapse
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom. Also, safestrap didn't do a thing with the bootloader, it was done during kernel init, right after firmware finishes. If a phone is hard bricked then adb won't work, and what I'm getting at is hard bricking it then using the debrick image thing
dreamwave said:
so far I've been able to downgrade just fine. Don't do anything with knox and it seems odin can flash back to the original Kitkat rom
Click to expand...
Click to collapse
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Click to expand...
Click to collapse
I don't know, I got it to go back to when root was still possible to get via an app. I don't see why there's a need to downgrade the bootloader if the debrick image thing works
tr4nqui1i7y said:
Even after updating past OE1? I thought nobody has been able to downgrade after accepting anything past that update.
Hm, I'd be really interested in finding a way to get the downgrade to work properly for users that updated. Perhaps packaging the safestrap into a rooted tar. I'm not sure. There has got to be a possibility. We've got all the pieces, we just need to put them together.
When you say you want to hard brick then debrick... Are you thinking that the bootloader might be ignored when it is in a broken state, allowing an older image to be written?
Click to expand...
Click to collapse
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
dreamwave said:
Exactly. Safestrap is basically useless for flashing bootloader and stuff as it has no firmware involvement. If the bootloader is the part that determines whether or not it's being upgraded or downgraded then if this works it could be downgraded. If they have a hardware counter that determines it, then a modified new bootloader could be flashed probably but not a previous version.
Click to expand...
Click to collapse
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
tr4nqui1i7y said:
I am not concerned with fllashing a bootloader. I am only trying to find a way to sneak the old exploit into the updated system via an old flaw.
Old System - Check
Root for old system - Check
init tweak - Check
New bootloader - Check
New system - Check
Rooted new system - Check
Old bootloader vulnerability - Check
New bootloader vuln - Missing
This means we either need to find a way to downgrade again, or find a root method for the new system.
What I am interested in is utilizing the init hack to spoof the old bootloader and allow for the new rooted system to boot for users who have taken updates past OE1.
Click to expand...
Click to collapse
but that has already been done I think, root on a system with any bootloader so long as a root exploit exists for the OS
That's safestrap. It doesn't allow custom kernels or a full custom recovery though, that's why I'm trying to modify the bootloader