Hello everyone! It's been six years since my last post and it is truly fantastic that this community is still going strong
A while back I installed LineageOS on a Motorola device. I am very impressed and very grateful to all the developers and the free software community for this amazing piece of software. I like to secure my devices as much as possible and I am wondering about the implications that an unlocked bootloader might present.
Some time ago I came across a post somewhere on the internet (unfortunately cannot find that link anymore) where someone claimed that if the bootloader of an Android device is unlocked, one could boot a TWRP recovery image, delete the encryption keyfiles and as a result the encryption keys would be reset to the default values and this would allow to bypass any screenlocks.
Unfortunately I don't have spare device to conduct tests, therefore I am hoping that someone could shed some light on this. Is it really possible to bypass FBE so easily with an unlocked bootloader?
From this answer on a different forum:
The main issue with LineageOS is that you will have an unlocked bootloader. That allows an attacker to load a custom recovery and brute force your encryption completely bypassing LineageOS all together.
Click to expand...
Click to collapse
An alternative would be conducting an Evil maid attack since Lineage is by default built in userdebug and allows flashing any (unsigned) packages from the ADB. Nothing is stopping anyone from flashing a keylogger or some kind of a remote access on your device using this method.
The questions remain how likely are such attacks and how likely will a potential thief invest his time and resources in getting access to your data. These are questions everyone has to answer depending on his own individual situation and risk factors.
Feel free to correct me
Thanks for the reply. You made some good points, I also think that if a device has been in the wrong hands even for a short period of time, it is compromised, even if the bootloader is locked down and USB debugging is disabled. Unlocked bootloader is a great gateway for bruteforce or dictionary attacks but a strong password can mitigate the risk and prevent even state actors from accessing the information, at least for couple of years
However the question still remains - Can LineageOS's FBE be bypassed if the encryption keyfiles are simply deleted?
Reacan said:
However the question still remains - Can LineageOS's FBE be bypassed if the encryption keyfiles are simply deleted?
Click to expand...
Click to collapse
No. Unless LineageOS's (or Android's) crypto is horribly broken, this shouldn't be possible. So far, the only way to bypass the drisk encryption is to brute force the passphrase. You are probably referring to erasing user data by removing encryption headers -- TWRP can do this, but then all your data is lost.
However, encryption only protects user data, not system. Hence, the latter can be backdoored without you knowing.
Reacan said:
However the question still remains - Can LineageOS's FBE be bypassed if the encryption keyfiles are simply deleted?
Click to expand...
Click to collapse
Afaik FBE works by generating a random key and encrypting the target parition(s) on the first boot. Then it uses your passphrase to encrypt that key.
From my understanding, deleting the key (stored in an encrypted form) would make the data encrypted with that key essentially unrecoverable. Unless someone had the resources to bruteforce the key. As of today that would require state level amount of resources.
Another theoretical possibility would be performing a Cold boot attack to get the encryption keys from RAM.
Feel free to correct me
Also remember if you are using a phone with a Qualcomm chipset, and you are really up against a state level actor, you also have to deal with EDL mode: you can dump the entire phone with it (no need to compromise or exploit the image on the phone itself), take it back to your seekret lair, and spend your gazillions on brute force hardware.
Bottom line, even if every senior hacker on this board told you "no, not that easy", they still could be wrong somehow. Zero days wouldn't be a thing if it worked that way. If you've got something truly worth protecting, put it in a [software] vault with solid, audited encryption.
If it isn't /that/ important, some phones will let you do the entire trusted boot thing if you want to compile LOS (or any AOSP based distro) from source, and futz around with the build scripts.
That said, remember there are social engineering attacks. If I were a l33t CIA agent, I'd probably wait till you were somewhere where I could watch you carefully (or had a 8 billion megapixel camera watching you carefully), send you a text message (marketing spam would work nicely), and then watch you type your password on the screen to read it... boom, pwn3d.
Many vectors of attack here.
If someone *GOT* your phone (to launch TWRP et al), you'd know about it, right? Consider a remote wipe package? Or try to keep them from getting it in the first place with physical security (vault, firearms, martial arts, etc)?
Related
A lot of phones will only boot if the firmware has a valid signature. Does the Samsung Wave check the firmware's signature (if there is one)?
In case of Bootloader I can confirm Signature check.
Because bricked after changing text...
boot_loader.mbn ---> yes, sure
dbl.mbn ---> not tested, but I think yes, because Qualcomm part...
All other files have no valid/mandatory Signature check.
You can modify all files.
Accept MD5 Hash for Multiloader, but this you can disable.
Handset self not check.
Best Regards
Can you tell us what you want to do??
Well, what I really want to know is if the hardware performs signature verification. For example, the bootloader in most HTC phones checks the signature of the firmware and will proceed to boot if it is valid. Replace the bootloader with your own custom bootloader and know checks are performed and you can put anything you want on it because the hardware does not check the signature of the bootloader. I also might want to modify Bada firmware, too. It is a different operating system or platform or whatever you want to call it and it looks like it would be fun to play around with. I own a Motorola DROID 2 Global.
Does anyone understand what I'm talking about?
Read it
http://forum.xda-developers.com/showpost.php?p=12213290&postcount=21
I'm afraid that is not clear enough. Has anyone tried to flash an alternative bootloader. And please, read my terminology. When I say bootloader, I mean software not the etched boot rom.
Has anyone tried to flash an alternative bootloader.
Click to expand...
Click to collapse
In case of our Flash Tool Multiloader we have only 2 files:
boot_loader.mbn----> "Samsung part"
dbl.mbn------------> "Qualcomm part"
As we have 2 CPU inside, 1 from Qualcomm... Call Processor, the other from Samsung = Application Processor.
So in most cases dbl.mbn is complete untouched in my tests. But I've failed in:
---> changing to oldest "unprotected" Boot XXJB6
---> changing to S8530 Boot (dbl.mbn is 1:1 same)
---> changing to modified S8500 Boot = bricked, but reanimated with JTAG
You can see my attempts here:
http://forum.xda-developers.com/showthread.php?t=897468
Boot means boot_loader.mbn, but I was tooo lazy to write full.
Best Regards
Master Melab said:
Has anyone tried to flash an alternative bootloader.
Click to expand...
Click to collapse
Oleg succeed doing it with JTAG. It is sure that it's also possible to do through FOTA, but there is almost no way to succeed at first try, so JTAG is also required there for the first tries. And... why would we do that? ;d
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
OK, getting to formal terminology there are several cryptographic services implemented on Wave bootloader level:
- integrity - on each loader stage
- authentication - modules loaded are verified using hardcoded (in BL3) public key
- confidentiality - some modules are encrypted using symmetric key cryptography
You may as well find some access control (implicit coming from symmetric key confidentiality and loading protocol requiring proper unlock procedure) and non-repudiation elements (storing the history of loaded components).
In more general view:
When talking about bootloader level software, it makes no sense to differentiate between hardware and software verification. It all comes to completeness of the verification chain. In most cases bootloader provides the only designated interface (with the presumption of not intruding hardware components) that is available for writing executable components into non-volatile memory used in the booting process.
Bearing that in mind, I would add to the locked bootloader definition that it does not only verify kernel, but verifies all executable components that take part in the booting process (including bootloader, of course).
Rebellos said:
Oleg succeed doing it with JTAG. It is sure that it's also possible to do through FOTA, but there is almost no way to succeed at first try, so JTAG is also required there for the first tries. And... why would we do that? ;d
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
Click to expand...
Click to collapse
What is [the] "iROM"?
Sent from my DROID2 GLOBAL using XDA App
mijoma said:
OK, getting to formal terminology there are several cryptographic services implemented on Wave bootloader level:
- integrity - on each loader stage
- authentication - modules loaded are verified using hardcoded (in BL3) public key
- confidentiality - some modules are encrypted using symmetric key cryptography
You may as well find some access control (implicit coming from symmetric key confidentiality and loading protocol requiring proper unlock procedure) and non-repudiation elements (storing the history of loaded components).
In more general view:
When talking about bootloader level software, it makes no sense to differentiate between hardware and software verification. It all comes to completeness of the verification chain. In most cases bootloader provides the only designated interface (with the presumption of not intruding hardware components) that is available for writing executable components into non-volatile memory used in the booting process.
Bearing that in mind, I would add to the locked bootloader definition that it does not only verify kernel, but verifies all executable components that take part in the booting process (including bootloader, of course).
Click to expand...
Click to collapse
Please define "BL3". (A stage 3 bootloader?) Yes good point about my definitions, I will add your suggestion. Does the Wave's bootloader use RSA, El Gamal, etc.?
Edit: But, in my mind it does make sense to differentiate the hardware and software.
Sent from my DROID2 GLOBAL using XDA App
Master Melab said:
What is [the] "iROM"?
Sent from my DROID2 GLOBAL using XDA App
Click to expand...
Click to collapse
iROM is a chip that contains code to load the very first bootloader from NAND, it cannot be modified i believe.
Rebellos said:
Also, iROM seems to perform some checksum validation, but as we can see from oleg's example - even without correct checksum it starts altered bootloader from oneNAND.
Click to expand...
Click to collapse
Catching errors, maybe?
Master Melab said:
Please define "BL3". (A stage 3 bootloader?) Yes good point about my definitions, I will add your suggestion. Does the Eave's bootloader use RSA, El Gamal, etc.?
Click to expand...
Click to collapse
Yes, I mean stage 3 bootloader.
There are 3 hardcoded public RSA keys. All 512 bit with 2^16+1 exponent.
Master Melab said:
Edit: But, in my mind it does make sense to differentiate the hardware and software.
Click to expand...
Click to collapse
Please justify the differentiation and define what you understand by hardware as I'm not sure whether you are really serious about it or not.
mijoma said:
Yes, I mean stage 3 bootloader.
There are 3 hardcoded public RSA keys. All 512 bit with 2^16+1 exponent.
Please justify the differentiation and define what you understand by hardware as I'm not sure whether you are really serious about it or not.
Click to expand...
Click to collapse
When I say "bootloader" think GNU GRUB and Windows' NTLDR—that is software. The reason for the differentiation is that the bootloader as defined in the PC world, the iOS hacking community, and other parts of the mobile development community is replaceable/flashable. When I refer to "hardware-based verification" I am talking about instructions physically etched on the chip that will perform some sort of signature or hash check of the lowest level of the boot chain. The "low level bootloader" or "LLB" in iOS is checked by the iPad/iPhone/iPod touch's boot ROM. The public key that is used to verify the LLB's signature is represented as physical breaks in the silicon.
Master Melab said:
When I say "bootloader" think GNU GRUB and Windows' NTLDR—that is software. The reason for the differentiation is that the bootloader as defined in the PC world, the iOS hacking community, and other parts of the mobile development community is replaceable/flashable. When I refer to "hardware-based verification" I am talking about instructions physically etched on the chip that will perform some sort of signature or hash check of the lowest level of the boot chain. The "low level bootloader" or "LLB" in iOS is checked by the iPad/iPhone/iPod touch's boot ROM.
Click to expand...
Click to collapse
Sorry, but if the area is not programmable it does not mean it's not software.
When thinking about 'embedded' world, leave the PC world alone. The list of differences is longer than the list of similarities.
Have a point there, but even if the verification is not done by hardware it does not mean it's replaceable (without hardware intrusion). The formal logic would require to show exploitable vulnerability first and there isn't a generic one.
Master Melab said:
The public key that is used to verify the LLB's signature is represented as physical breaks in the silicon.
Click to expand...
Click to collapse
LOL. Sounds like written with blood. Maybe I'm not English native and that's the reason I didn't get it, but could you elaborate (you may go deep without worries) on the method of creating 'physical breaks in the silicon' as it does not seem to be scientific term? It does, however, seem just as a description of a form of 'non-volatile memory'.
What value does the strict lowest level protection policy have when higher level introduce (with increasing probability with each level) vulnerabilities easier to exploit?
Does the Wave's bootloader use RSA, El Gamal, etc.?
Click to expand...
Click to collapse
RSA I've seen.
El Gamal never heard.
etc. not sure...
Maybe if you have some time and you are willing to learn with us. For instance here:
http://forum.xda-developers.com/showpost.php?p=13522665&postcount=50
In Firmware files are many Certs included... few of them seems to have also private parts... but encrypted... example:
EncryptedDevcerttemplateFile
EncryptedPrivKeyFile
According to other Samsung handsets... folder Security is also available on other models... few Certs should be same...
No idea if all Certs are usefull... but maybe fun to train brain.
Best Regards
mijoma said:
Have a point there, but even if the verification is not done by hardware it does not mean it's replaceable (without hardware intrusion).
Click to expand...
Click to collapse
Please, explain.
mijoma said:
LOL. Sounds like written with blood. Maybe I'm not English native and that's the reason I didn't get it, but could you elaborate (you may go deep without worries) on the method of creating 'physical breaks in the silicon' as it does not seem to be scientific term? It does, however, seem just as a description of a form of 'non-volatile memory'.
Click to expand...
Click to collapse
Things like a BIOS or true read only memory have instructions or data encoded into the layout of the circuitry itself. Usually, fuses are either broken or left intact and this may either mean a 1 or a 0, depending on the manufacturers device works.
adfree said:
RSA I've seen.
El Gamal never heard.
etc. not sure...
Maybe if you have some time and you are willing to learn with us. For instance here:
http://forum.xda-developers.com/showpost.php?p=13522665&postcount=50
In Firmware files are many Certs included... few of them seems to have also private parts... but encrypted... example:
EncryptedDevcerttemplateFile
EncryptedPrivKeyFile
According to other Samsung handsets... folder Security is also available on other models... few Certs should be same...
No idea if all Certs are usefull... but maybe fun to train brain.
Best Regards
Click to expand...
Click to collapse
adfree, when I say "etc." I mean "et cetera", which in Latin means "and other things" or "and so forth". El Gamal is another asymmetric cryptosystem that relies on the difficulty of factoring a large composite number, just like RSA.
And thank you for the file.
I'm not sure where this threat should goes, as it should be Windows RT Troubleshooting but there isn't such forum. Please don't delete it.
The Problem:
Now, if I turn on Surface, under the Logo it says "Preparing BitLocker recovery"
and ask me for BitLocker key to continue.
After I enter the key, the "unlock" was successful and goes to Recovery,
but everything after that failed:
1. If I choose Exit and continue to Windows RT, I got locked out again and everything above happened again. Infinity loop.
2. Same thing if I choose Turn off your PC, I turn it on and I was again locked out.
3. Automatic Repair couldn't repair, Refresh& Reset stuck on 1%.
How this was caused:
I had my Surface RT unlocked (jailbreak) using Netham45's RT Jailbreak Tool 1.1.1 during that boot:
I was using a normal Metro app (PPTV) to download some video just as usual, and I closed my cover to put it in sleep mode. Several minutes later I found out the power was off (it suddenly shutdown) , from then it stays in the locked out infinity loop.
I have seen similar situation when "testing signing mode is on":
mamaich said:
But be careful when hacking. There are known problems with BitLocker when test signing mode is on. The OS simply would not boot. Lets hope that we could disable BitLocker on our devices...
Click to expand...
Click to collapse
(The Original threat this came from)
So it might because the sudden shut down didn't turn of the test signing mode, so BitLocker locked me out.
Anyone has idea what to do to make my Surface working again? Anyway to disable test signing mode using Command Prompt? I don't care about my files inside!
shog7n said:
So it might because the sudden shut down didn't turn of the test signing mode, so BitLocker locked me out.
Click to expand...
Click to collapse
Seems unlikely, as the "jailbreak" is in-memory only. More likely some catastrophic corruption of storage happened.
This is not a dev or hacking issue; this thread belongs in General or Surface if it belongs anywhere on XDA-Devs at all.
I'm going to agree with schettj here; this sounds like storage corruption. Contact support and see if you can get a warranty replacement. Don't mention the jailbreak, obviously, but since it is in-memory only it shouldn't matter (although it's possible that the jailbreak might cause a kernel memory corruption that messes up the storage stack but doesn't cause a bluescreen, this seems unlikely).
Incidentally, if it's a production device, you can be sure you weren't in testsigning mode to begin with unless there's a lot more hacks out for RT than I'm aware of; the SecureBoot configuration prohibits testsigning. Also, you shouldn't be getting asked for the BL recovery key unless you messed with either the bootloader or the EFI image. If you didn't do those things and are getting prompted anyhow, that reinforces the likelihood of a problem with the device storage.
This is (most likely) nothing to do with the jailbreak. If you can get your hands on a recovery drive you may be able to use it to reinstall windows, else take it back to MS and don't mention the jailbreak to them.
Or just decrypt the bitlocker volume from the recovery mode. It would be automatically reencrypted at the next boot.
To decrypt - boot to recovery with CMD, enter bitlocker recovery key, then run the command "manage-bde.exe -off c:"
this would start the decryption process and exit immediately. To check the progress - periodically type "manage-bde.exe -status". Here is the tool command line reference: http://technet.microsoft.com/en-us/library/dd875513(v=ws.10).aspx
But in the case if this is a disk corruption - I'd recommend to checkdisk it first from the recovery console ("chkdsk c: /offlinescanandfix").
GoodDayToDie said:
Also, you shouldn't be getting asked for the BL recovery key unless you messed with either the bootloader or the EFI image.
Click to expand...
Click to collapse
BitLocker recovery key is asked on every boot into the recovery environment, otherwise it would be unable to mount the C:, at least on my device I see this behavior. It may be kept in TPM - I don't know, but my device always asks it in recovery.
Once I was able to permanently decrypt the disk so that it was not reencrypted at next windows boot - but I don't remember what I've done, and I've trashed all settings when playing with recovery USB
A fair point. But, it shouldn't *be* booting to recovery unless the button combo to do so is pressed, or that option was selected at shutdown. Typically, you would at least get a bootloader menu offering a normal bootup or a recovery session...
GoodDayToDie said:
A fair point. But, it shouldn't *be* booting to recovery unless the button combo to do so is pressed, or that option was selected at shutdown. Typically, you would at least get a bootloader menu offering a normal bootup or a recovery session...
Click to expand...
Click to collapse
If the bootloader fails to load the core resources (winload.efi, ntoskrnl.exe, I believe) that are required on the system partition it should automatically boot to recovery.
Recovery
I've ran into a similar situation, when I played around with some startup options for the Surface. The only way I was able to recover was to reset the settings on the Surface. (OS Refresh) You can try the other recovery options, like system restore, or try booting into safe mode. If you can get to safe mode you can try disabling the startup of the Jail Break tool. If that doesn't work than I doubt the jail break was even related to the problem you are experiencing. (it is already highly unlikely that this is the case.)
Good luck.
Zephnath said:
I've ran into a similar situation, when I played around with some startup options for the Surface. The only way I was able to recover was to reset the settings on the Surface. (OS Refresh) You can try the other recovery options, like system restore, or try booting into safe mode. If you can get to safe mode you can try disabling the startup of the Jail Break tool. If that doesn't work than I doubt the jail break was even related to the problem you are experiencing. (it is already highly unlikely that this is the case.)
Good luck.
Click to expand...
Click to collapse
It's not even getting to the point where the jailbreak would run.
netham45 said:
It's not even getting to the point where the jailbreak would run.
Click to expand...
Click to collapse
Believe me I know where it is getting to. However if there is a remote possibility that the jailbreak affected the startup processes of the OS, then removing the jailbreak could revert those changes, however unlikely it is still worth attempting.
As I said the possibility is unlikely. Which is why a system restore and OS refresh are most likely the only options.
Zephnath said:
Believe me I know where it is getting to. However if there is a remote possibility that the jailbreak affected the startup processes of the OS, then removing the jailbreak could revert those changes, however unlikely it is still worth attempting.
As I said the possibility is unlikely. Which is why a system restore and OS refresh are most likely the only options.
Click to expand...
Click to collapse
That doesn't even make sense. It doesn't boot into Windows, let alone to the point where the user can log in and the task scheduler can be initialized, so there's no way it's also booting for the two minutes it takes for the jailbreak to launch.
I received a Vivotab tf600t. When I turn it on, it goes to Preparing Automatic Repair and then goes to Diagnosing Your PC. It never gets out of this loop--Prepaing then Diagnosing. Is this due to jailbreak gone wrong? Any chance to factory reset it? TIA.
9394888 said:
I received a Vivotab tf600t. When I turn it on, it goes to Preparing Automatic Repair and then goes to Diagnosing Your PC. It never gets out of this loop--Prepaing then Diagnosing. Is this due to jailbreak gone wrong? Any chance to factory reset it? TIA.
Click to expand...
Click to collapse
What was done before it went into this infinate loop? Chances are the Jailbreak didn't do it.
There is a way to factory reset the tablet. You will need the Bitlocker key, if you don't have it you can recover it from your skydrive. Use this url to go to the recovery keys attached to your skydrive account: http://skydrive.com/RecoveryKey (you will have to logon with the primary microsoft account for your tablet)
You should be able to get into the advanced recovery options for the tablet, some of which will allow you to reset the tablet (which wipes the tablet of everything, thus restoring it to factory defaults), or to refresh the tablet (which uninstalls programs but maintains files and documents)
Zephnath said:
There is a way to factory reset the tablet. You will need the Bitlocker key, if you don't have it you can recover it from your skydrive. Use this url to go to the recovery keys attached to your skydrive account: http://skydrive.com/RecoveryKey (you will have to logon with the primary microsoft account for your tablet)
You should be able to get into the advanced recovery options for the tablet, some of which will allow you to reset the tablet (which wipes the tablet of everything, thus restoring it to factory defaults), or to refresh the tablet (which uninstalls programs but maintains files and documents)
Click to expand...
Click to collapse
Excellent piece of information.
A brief history:
Several weeks ago my stock Gingerbread G2's touchscreen started dying. Replacing the touchscreen didn't solve the problem. I was able to continue using it via the keyboard for a little while and, in the meantime, enabled USB Debugging (thank the stars!) while I waited for a replacement phone to arrive. I could still access some functions using the keyboard & thumbpad, although usability was limited due to the inability to back out of an application. Cue lots of battery pulls to restart at the homescreen (a pox on designers who forget one of the fundamental rules of UI: It should always be possible to go back using the current input device!).
Then the screen started a somewhat frazzled HTC image loop during boot, shortly after I started testing ADB & fastboot. Curiously it was still booting the underlying OS, as evidenced by the various chimes telling me I had messages etc, and I could still access it via ADB.
My new phone arrived (a Sony Xperia Z3 Compact. I still would prefer a proper keyboard though. Another pox on designers/manufactures who focus on marketing fads instead of functionality. I don't give a rat's arse if my phone is only 2.48291mm thick and has a screen the size of my 1st laptop. I want something small enough to use in one hand, and that has a hardware keyboard) & happily downloaded my contacts from the Borg....I mean, Google, but not notes or SMS/MMS etc. Leading to today....
I tried Sony's transfer app, but without screen viewing let alone touchscreen ability it wouldn't work (PC version, due Android version on the problem phone wasn't acceptable). Ditto problems with other root exploits. Even trying to use a recovery image on the SD card wouldn't work due to the non-root status. The recovery menu would only accept a stock image. An overriding consideration was that I didn't want to just gain root by what ever method, but I wanted to preserve my notes & sms/mms data, so fastbooting a factory image wasn't satisfactory - as far as I could tell, that would delete everything. After over a week of 0300, 0400, 0530 bed times while reading & trying the methods given in some huuuge number of XDA threads and some other websites, last night I was able to get temp root using the fre3vo exploit! Yay! At one point I had 70 threads open. It was an XDA-dev. thread that gave me the exploit though. Still couldn't do a simple Linux/Unix cp command in ADB shell to save the data but at least the file system was accessible now. Bloody frustrating!
Anyway, a bit more Googling & XDA-ing to find file locations & command formats and tonight I was able to use the ADB pull command to download the whole of the /data directory to my PC. Data saved! Even better, the Linux distro on my PC already has SQlite software to open the files. Even more yay!
I haven't tried to upload to my Xperia Z3C, but I will soon. Meanwhile my data is now available in my PC so phone access isn't as important anymore.
Some thoughts on what I went through:
Manufacturers: You do your customers a vast dis-service by making it so hard to salvage the data.
Service providers: Ditto, due to your insistance on locking down the system on the phones you sell
XDA contributers: I couldn't have done this without you, however.....it would have been easier if you *always* specified what would change/be wiped when you describe your exploit/change/recovery process. I was hesitant to try some methods due to not knowing if my data would be wiped in the process.
And after all that: Who the hell would ever want a phone that wasn't rooted? I don't even install Linux OS on my systems unless root can be gained (Ubuntu & Mint, I'm looking at you! Sudo isn't sufficient...) so I've learnt a lesson on my phone. If only I'd rooted it while it was still fully functional!
Next task? Rooting my Z3C before something goes ' bzzzzt!' on it!
I need root access without failure to my Verizon Google pixel xl 1 ASAP. Is it possible for me to purchase a certificate/license from the manufacturer in order to get root privileges?
Reason being I cannot risk failure as I need to run a data recovery, to recover a large audio file that is to be used to clear someone who was coerced into taking a plea deal by a prosecutor.
The file is beyond important to our case and it seems Google removed the file in a "clear up space" task that was executed on it.
Everything we have read so far says root access is a must have in order to be able to recover deleted files.
dcheck246 said:
I need root access without failure to my Verizon Google pixel xl 1 ASAP. Is it possible for me to purchase a certificate/license from the manufacturer in order to get root privileges?
Reason being I cannot risk failure as I need to run a data recovery, to recover a large audio file that is to be used to clear someone who was coerced into taking a plea deal by a prosecutor.
The file is beyond important to our case and it seems Google removed the file in a "clear up space" task that was executed on it.
Everything we have read so far says root access is a must have in order to be able to recover deleted files.
Click to expand...
Click to collapse
What is the current status of the bootloader on the device (locked/unlocked)? What is the current software version / build on the device?
I suspect that your best bet would be to contact Google and/or Verizon and request their assistance. If the bootloader is NOT currently unlocked, then unlocking it (even if method existed) would result in the device being wiped as part of that process - which MIGHT impact your ability to retrieve the deleted file. If you are on an older version/build, I know there were some versions that allowed for some root exploits to work without requiring the bootloader to be unlocked - but those have long since been closed. Given the critical nature of your need, I think your best bet would be to engage Google or Verizon for the assistance you need...perhaps with the legal context behind the request, they would consider an exception to their typical policies. Not sure if you could secure a court order or similar to compel them to help you...but I think your best bet is to have Google or Verizon assist to avoid any unnecessary risk to permanently losing the file you are seeking to restore/recover.
Good luck!
Read the last couple pages of this thread...
https://forum.xda-developers.com/pixel-xl/how-to/verizon-pixel-bootloader-unlocked-t3726672/page20
Short version of question: How can I unbrick my ONEPLUS 3 (A3000) if I cannot boot to Android and OEM Unlock AND USB Debugging both have not been enabled?
Long version: Phone was recently purchased second hand from a third-party market (Kijiji, kind of like craigslist for Canadians). Person I bought it from claimed in the ad that the device was in a bootloop and couldn't access the OS. I had in the past successfully saved a ONEPLUS 1 from bricked status, so I didn't feel a simple bootloop would pose much of an issue. That, and at the price he was selling I really couldn't turn it down.
I tried various different methods of restoring the phone's partitions, OS, and firmware to stock/custom, but had no real luck with any (I will list below what I have attempted). If there was a root cause of this, I believe it's due to the fact that some part of the phone's storage partition (boot or system if I had to guess) had become corrupted at some point. Given the volume of threads I've seen here and elsewhere online, I wouldn't rule out a bad OTA flash, but doesn't really matter. What does matter, however, is that the Android OS is inaccessible despite my best efforts, and the bootloader is set to locked and ADB Debugging remains off.
Generally speaking, is there a way to access Developer Options to correct both these issues through terminal or a tool? I'm confident that I can get my device working again if I could access this menu, but as of yet I have had no luck.
Methods used to restore/info worth mentioning
While I don't doubt their effectiveness at large, for whatever reason I have yet to find a tool/guide that yields the anticipated results upon completion. MSM Download Tool (V3 and V4) have both been downloaded, executed, and completed numerous times, but will still not boot past the loading screen upon completion.
According to Unified Android Toolkit, my device build is being detected as "OnePlus3 7.0 NRD90M" and All-in-One Toolkit is showing that Android 6.0.1 is installed.
Drivers are all installed correctly, as proven both via tools downloaded and through Windows CMD terminal (adb devices, fastboot devices, adb get-state, etc)
Stock recovery and bootloader modes can both be reached through both hardware keys and software commands. I will note that it seems to take longer than I'd expect to boot to either of these modes using hardware keys.
I have utilized multiple USB ports, Type-C cables, different OS' on two laptops (MS Windows 10 and 7, FWUL Linux). I usually have no problem with the device being detected by the system. When I have, it usually involved one pesky USB cord.
common commands used and their effects:
fastboot OEM unlock: fails, cannot be done remotely
fastboot flash x: fails, remote: flashing partitions not allowed
ADB push: fails. cannot access partition
ADB devices: device is seen by system with serial and state
fastboot devices: device is seen by system with serial
ADB sideload: varying results. Some will fail at 0% citing "total xfer: 0.00x", some will reach 47% and fail (always exactly 47% oddly). Generally if the sideload operation passes 47% it will complete.
fastboot format/erase x: fails, partition formatting/erasing not allowed
fastboot continue: executes, but does not help with android bootloop issue as I had hoped
While I searched for an answer online, I did come across an infosec whitepaper regarding ONEPLUS 3 vulnerabilities, though it was over a year old. To my surprise, the command they had been entering works on my device, but I'm not sure how to properly use it effectively. The command used was fastboot OEM boot_mode [rf/wlan/ftm/normal]. Now, I was unable to determine what each of the triggers does, but what I did discover is that with boot_mode set to rf, my device would display chinese/korean lettering in lieu of the usual ONEPLUS logo with "powered by Android" below. This is also how I managed to have my device show up in CMD terminal for ADB commands to be issued. To the best of my knowledge though, there doesn't seem to be much point to it as I couldn't push/pull any files. Does anybody know where I could find more info on this command, as I'd like to know what the other triggers accomplish.
I've just about exhausted every available resource looking for an answer, but im still coming up short. I've gone as far as contacting ONEPLUS directly, but without proof of purchase they can't (more accurately won't) help me. And while it's not a business practice I would personally support, I can understand why they have it implemented. I've contacted a few phone shops in the area, but none have been able to assist me further than I've already gotten in this process.
I apologize again for creating a new thread about this, but I felt my circumstances warranted a new thread due to the bulk of the others having either an unlocked bootloader or TWRP installed, neither of which I do.
So, can anybody offer their help or suggest something I haven't already tried? Or should I be on EBAY looking for motherboards? Thanks in advance.
Calgary84 said:
Short version of question: How can I unbrick my ONEPLUS 3 (A3000) if I cannot boot to Android and OEM Unlock AND USB Debugging both have not been enabled?
Long version: Phone was recently purchased second hand from a third-party market (Kijiji, kind of like craigslist for Canadians). Person I bought it from claimed in the ad that the device was in a bootloop and couldn't access the OS. I had in the past successfully saved a ONEPLUS 1 from bricked status, so I didn't feel a simple bootloop would pose much of an issue. That, and at the price he was selling I really couldn't turn it down.
I tried various different methods of restoring the phone's partitions, OS, and firmware to stock/custom, but had no real luck with any (I will list below what I have attempted). If there was a root cause of this, I believe it's due to the fact that some part of the phone's storage partition (boot or system if I had to guess) had become corrupted at some point. Given the volume of threads I've seen here and elsewhere online, I wouldn't rule out a bad OTA flash, but doesn't really matter. What does matter, however, is that the Android OS is inaccessible despite my best efforts, and the bootloader is set to locked and ADB Debugging remains off.
Generally speaking, is there a way to access Developer Options to correct both these issues through terminal or a tool? I'm confident that I can get my device working again if I could access this menu, but as of yet I have had no luck.
Methods used to restore/info worth mentioning
While I don't doubt their effectiveness at large, for whatever reason I have yet to find a tool/guide that yields the anticipated results upon completion. MSM Download Tool (V3 and V4) have both been downloaded, executed, and completed numerous times, but will still not boot past the loading screen upon completion.
According to Unified Android Toolkit, my device build is being detected as "OnePlus3 7.0 NRD90M" and All-in-One Toolkit is showing that Android 6.0.1 is installed.
Drivers are all installed correctly, as proven both via tools downloaded and through Windows CMD terminal (adb devices, fastboot devices, adb get-state, etc)
Stock recovery and bootloader modes can both be reached through both hardware keys and software commands. I will note that it seems to take longer than I'd expect to boot to either of these modes using hardware keys.
I have utilized multiple USB ports, Type-C cables, different OS' on two laptops (MS Windows 10 and 7, FWUL Linux). I usually have no problem with the device being detected by the system. When I have, it usually involved one pesky USB cord.
common commands used and their effects:
fastboot OEM unlock: fails, cannot be done remotely
fastboot flash x: fails, remote: flashing partitions not allowed
ADB push: fails. cannot access partition
ADB devices: device is seen by system with serial and state
fastboot devices: device is seen by system with serial
ADB sideload: varying results. Some will fail at 0% citing "total xfer: 0.00x", some will reach 47% and fail (always exactly 47% oddly). Generally if the sideload operation passes 47% it will complete.
fastboot format/erase x: fails, partition formatting/erasing not allowed
fastboot continue: executes, but does not help with android bootloop issue as I had hoped
While I searched for an answer online, I did come across an infosec whitepaper regarding ONEPLUS 3 vulnerabilities, though it was over a year old. To my surprise, the command they had been entering works on my device, but I'm not sure how to properly use it effectively. The command used was fastboot OEM boot_mode [rf/wlan/ftm/normal]. Now, I was unable to determine what each of the triggers does, but what I did discover is that with boot_mode set to rf, my device would display chinese/korean lettering in lieu of the usual ONEPLUS logo with "powered by Android" below. This is also how I managed to have my device show up in CMD terminal for ADB commands to be issued. To the best of my knowledge though, there doesn't seem to be much point to it as I couldn't push/pull any files. Does anybody know where I could find more info on this command, as I'd like to know what the other triggers accomplish.
I've just about exhausted every available resource looking for an answer, but im still coming up short. I've gone as far as contacting ONEPLUS directly, but without proof of purchase they can't (more accurately won't) help me. And while it's not a business practice I would personally support, I can understand why they have it implemented. I've contacted a few phone shops in the area, but none have been able to assist me further than I've already gotten in this process.
I apologize again for creating a new thread about this, but I felt my circumstances warranted a new thread due to the bulk of the others having either an unlocked bootloader or TWRP installed, neither of which I do.
So, can anybody offer their help or suggest something I haven't already tried? Or should I be on EBAY looking for motherboards? Thanks in advance.
Click to expand...
Click to collapse
Thanks for the exhaustive description. You seem to have covered every known method. If the MSM Tool also fails, I think that it is a hardware issue and you are better off searching for a new motherboard instead of wasting further time on trouble-shooting.
Best of luck!
tnsmani said:
Thanks for the exhaustive description. You seem to have covered every known method. If the MSM Tool also fails, I think that it is a hardware issue and you are better off searching for a new motherboard instead of wasting further time on trouble-shooting.
Best of luck!
Click to expand...
Click to collapse
I was afraid of that..... is there a way to test a given hardware component?
Have you tried the unbrick tool FULL updated: https://mega.nz/#!NmhhgZyB!CM7Fw8VjECiMIhh4gRXUx24QVCiE599_ZFAPDf08AiM
acetone802000 said:
Have you tried the unbrick tool FULL updated: https://mega.nz/#!NmhhgZyB!CM7Fw8VjECiMIhh4gRXUx24QVCiE599_ZFAPDf08AiM
Click to expand...
Click to collapse
Indeed I have, dozens of times between the full and mini versions. I've even gone as far as running the toolkits featuring MSMDownloadTool v4.0 to see if it achieved different results (it did not). The mini tool would finish doing its thing (turned the text green upon completion),but I would face varying partitions not being flashed correctly. The full version completes and does not have these varying partitions missing, but the device would then be either stuck in a bootloop where it will eventually reboot itself, or would hang indefinitely on the "swirling dots" loading screen. I tried the remedy of deleting cache in recovery, but this did not help.
deleted
***UPDATE*** - As I mentioned in this thread earlier, I noticed a discrepancy between the variant type listed on my actual device and the variant type returned when queried via fastboot. This got me thinking, and to make a long story somewhat shorter, I found that while most stock Oxygen images I attempt to sideload onto the device fail (at precisely 47%, oddly), I was able to sideload two different Hydrogen images without any resistance at all. I'm guessing something to do with the eMMC vs UFS file storage systems and how each OS uses them.
So I got Hydrogen flashed onto my my device. Smooth sailing, right? Afraid not. Despite fastboot's output clearly stating it was a successful transfer, and the stock recovery on the device echoing this, I still cannot get the OS to load. Now i' stuck with the loading screen hanging indefinitely prior to animation occurring, so basically the static ONEPLUS logo. Factory resets and cache wipes have done nothing to help the situation along. Conventional wisdom from the threads here seem to say using the MSMTool is the right answer..... and thus the circle of frustration is complete with me arriving back where I started. Does anybody have another suggestion I can try out? Still can't flash/boot to TWRP, unlock bootloader, or access Android to activate USB Debug/OEM Unlock either btw.
Have you tried flashing just the firmware, i havent flashed in years but i would assume you could sideload the firmware as well?
voodooline said:
Have you tried flashing just the firmware, i havent flashed in years but i would assume you could sideload the firmware as well?
Click to expand...
Click to collapse
Guess who didn't read? And after a year without flashing + a lack of reading skills, you still think you could solve this case? That's a spirit.
===
You better do pm some devs in dev section and point them to this thread and see if they can help, if you are still curious.
My guess is dead emmc, it can be replaced without buying the whole board.
150208 said:
Guess who didn't read? And after a year without flashing + a lack of reading skills, you still think you could solve this case? That's a spirit.
===
You better do pm some devs in dev section and point them to this thread and see if they can help, if you are still curious.
My guess is dead emmc, it can be replaced without buying the whole board.
Click to expand...
Click to collapse
I did read it, its funny always someone who has to be a **** about things. I should have been more specific. He was able to flash h2os. So he could try to flash the firmware for h2os to see if that gets it to boot.
voodooline said:
I did read it, its funny always someone who has to be a **** about things. I should have been more specific. He was able to flash h2os. So he could try to flash the firmware for h2os to see if that gets it to boot.
Click to expand...
Click to collapse
Magnificent, bro.
You're a truly genius.