Database Info

Password Protect ADB?

Has anyone thought about implementing password protection to the G1's adb interface? If someone finds (steals) your phone, it' seems like they can get easy access to your data using adb if it is enabled? Instead of forcing the default to adb-debug disabled, it seems like requiring a password would be more useful?
I realize that this might be risky since it might prevent recovery when the password is forgotten, but at that point, there is still the "wipe all my data" unlock method right?
Without this, I find it hard to trust any sensitive data to my phone (since I do not want to toggle adb on/off constantly).

I agree with you any one who find our g1 or steal it, can find easy in the internet how to use adb, or they can even find out how you can do a wipe if you turn the phone off and start the phone using Home+Power button. And they will be good to go to use the G1. I hope someone can add a password protection to this 2 options.

I guess it might be nice to add a password option to the "wipe" option, but that seems like it would sorta defeat the purpose then, wouldn't it?
I am more concerned about my data than the device itself. If someone steals my phone and they can't use it, it doesn't really help me. But, if I can at least prevent them from reading my data... I envision using my phone as a secure token to access various logins at some point (anyone want to code that up? . So, I just want to ensure that they cannot get any keys/passwords on it.
The other problem with preventing someone from wiping it is, "what do you do if you forget your own password"? I would prefer to let the thief use the phone (without my data) than to potentially brick the phone for myself. Lastly, locking it permanently off to thieves would not be a deterrent to theft unless every phone did it since they would not know about it until they stole your phone!
I am surprised that the "serious" hackers have not implemented adb protection yet, have they?

Yea its kinda a good and bad thing tho. Look at it like this .
You put the password on your phone to stop people from doing anything to it, then you forgot your password, how do you get back in? You cant. Unless you have a way around that which if you have a way around that the thief would to.
The only thing i would like is to be able to protect files so if you lost your phone someone wouldn't be able to get into it without wiping the phone.

xile6 said:
Yea its kinda a good and bad thing tho. Look at it like this .
You put the password on your phone to stop people from doing anything to it, then you forgot your password, how do you get back in? You cant. Unless you have a way around that which if you have a way around that the thief would to.
The only thing i would like is to be able to protect files so if you lost your phone someone wouldn't be able to get into it without wiping the phone.
Click to expand...
Click to collapse
I agree with you and at the same time don't (right now I don't put personal files in my sd for that very reason if I lost the phone anyone can see what I have on the sd) regarding to the password I guess that it will be up to the people if you know that you forget passwords just don't use it I personally use 2 password 1 for forum 6 letter something simple and easy to remember, and one for (very important stuffs) 12 characteres letters and numbers. Plus I thing that everyone in that will be using this are people to frequent this forum wich I don't think they tend to forget passwords.

In order to gain access to program data (not applicable to sdcard), you still need to be either root, or to possess the userid of the particular program whose data you're trying to gain access to. Use of one of those secure-root password prompt programs will give you the ability to limit root access since the 'su' command will fail without the password being entered in the GUI.
This is not absolute though, since you can still boot on a recovery image, backup, and extract. Without actually encrypting the storage, there is no way to absolutely protect your data, and with a mobile device, the encryption/decryption overhead will take up too much CPU time to be practical. It could, however, be implemented on a program-by-program basis or on a data-but-not-program basis, i.e. encrypt /data/data, or /data/data-enc might be a better idea - leave data for user-programs encrypted, but system-services unencrypted, and mount the encrypted partition on screen unlock (i.e. password unlock). LUKS would be great for this. Allowing optional encryption for SD-card and allowing multiple SD-card partitions to be mounted (i.e. one encrypted, one not) would be ideal.

Well, perhaps the bootloader should get a password also? Would having both an adp and a bootloader passwords secure things completely?

Of course not. Bootloader passwords are virtually useless. All they do is stop you from booting, they do nothing at all to protect your data except from a real amateur, the likes of whom wouldn't be able to get your data off the thing even WITH root access.
As long as there is unencrypted data stored on the device, it definitely can be read off.

Could you please explain why you believe that a bootloader password would not work?
In other words, if a user is locked out from performing commands via the screen without the appropriate gesture, locked out from using adb without a password, and they cannot boot into the recovery image (or access NVRAM with fastboot) without a password, how can they access data on the internal NVRAM? I am not saying they can't (I don't know), I am asking what method you think they could use? Can the NVRAM be easily removed and plugged into another device and read? Are there other boot methods that I am not aware of (likely, I am fairly new to this) that would allow them to access the data? Or, are you just assuming that there is a method that an intelligent cracker could use?

1) you can use fastboot to boot off a recovery image file that is NOT ON THE PHONE,
2) you can connect directly to the chip and read its contents.
etc.
Keep in mind the way that bootloader passwords work; the password is NOT embedded in the bootloader - that would be stupid since you risk bricking the device every time you change the password. A password protected bootloader will access some configuration file that will have the details of the password. Fastboot would (and must) come before this stage.

It seems like you are pretty much just repeating/rewording the weaknesses already pointed out? I am not trying to be rude, if you do have some extra info, or there is something subtle that I am missing, please accept my apologies.
Specifically:
#1 should be assumed to be prevented by the bootloader password, no? Is there any reason you think this would not be effective?
As for #2, I was already asking if the NVRAM could easily be removed from the HTC? Do you have any useful info on this, on what it would take to do it? I assume this would require surface mount de-soldering?
My personal threat model would assume that my data is less valuable to a thief than my phone is. While I would prefer my data to not be easily acquired by a thief, I have nothing so secret that I would expect a thief to specifically steal my phone for it. Therefor, I assume that a thief has no incentive to destroy my phone (which he is in possession of and can use) just to get at my data. Of course, if there is an easy method to get my data (there currently are easy software methods), I would expect a thief to do so. I am hoping to close those easy software methods. If there are easy hardware methods, such as unplugging a chip or sdcard and simply inserting it into another phone, well, then perhaps the software holes are not worth plugging. But, any hardware hacks involving soldering (especially surface mount soldering) the phone are beyond my desire to foil.
Again, that is my personal objective, I understand if you do not share it. Can you think of any additional info that might be valuable with this in mind?
Thanks!

MartinFick said:
#1 should be assumed to be prevented by the bootloader password, no? Is there any reason you think this would not be effective?
Click to expand...
Click to collapse
No, bootloader password won't help you here, and I already explained why.
As for #2, I was already asking if the NVRAM could easily be removed from the HTC? Do you have any useful info on this, on what it would take to do it? I assume this would require surface mount de-soldering?
Click to expand...
Click to collapse
Sure, thats one way. The other way is by whatever mechanism HTC uses to initially write the bootloader to the device. I haven't looked, but there is probably a jtag port or something similar on it somewhere.
My personal threat model would assume that my data is less valuable to a thief than my phone is. While I would prefer my data to not be easily acquired by a thief, I have nothing so secret that I would expect a thief to specifically steal my phone for it. Therefor, I assume that a thief has no incentive to destroy my phone (which he is in possession of and can use) just to get at my data. Of course, if there is an easy method to get my data (there currently are easy software methods), I would expect a thief to do so. I am hoping to close those easy software methods. If there are easy hardware methods, such as unplugging a chip or sdcard and simply inserting it into another phone, well, then perhaps the software holes are not worth plugging. But, any hardware hacks involving soldering (especially surface mount soldering) the phone are beyond my desire to foil.
Again, that is my personal objective, I understand if you do not share it. Can you think of any additional info that might be valuable with this in mind?
Click to expand...
Click to collapse
Unfortunately, even if it were possible, securing it against that possibility isn't going to help you since the thief doesn't know that its worthless to him. He'll steal it anyways, and then garbage it when it turns out to be useless to him.

No, bootloader password won't help you here, and I already explained why.
Click to expand...
Click to collapse
Uh, no you didn't. You rambled on about the password being in some config file and therefore assumed that it would not be possible or desirable to actually implement a proper bootloader password. I do not accept this criticism, people reflash their bootloaders all the time and it is up to them to determine the level of "brick risk" they want. Perhaps you don't like it, that doesn't make things impossible.
As for putting the password in a config file somewhere, it is not the only solution, one could easily create a separate tiny partition just for the password if you did not want to put FS reading code into the bootloader. (That was your point, right? That the bootloader is simple and cannot read a filesystem?) Surely the bootloader knows how to read partitions, or how would it be able to boot the kernel? With this you could reduce most "brick risk" by providing a "boot from external kernel for recovery after wiping the partitions" option.
And, finally, perhaps there is some other minimal byte storage on the HTC Dream where a password could be easily stored? Something analogous to the CMOS of a PC, something the bootloader could easily read/write to change the password?
Sure, thats one way. The other way is by whatever mechanism HTC uses to initially write the bootloader to the device. I haven't looked, but there is probably a jtag port or something similar on it somewhere.
Click to expand...
Click to collapse
Valid concern, easy for someone with the right tools, and some very specialized expertise perhaps. I would be plenty happy to foil all thiefs who do not own such tools or have such knowledge, I believe those are the ones likely to steal my phone.
Unfortunately, even if it were possible, securing it against that possibility isn't going to help you since the thief doesn't know that its worthless to him. He'll steal it anyways, and then garbage it when it turns out to be useless to him.
Click to expand...
Click to collapse
Why is not going to help me? If he can't get my data (easily without desoldering), it helps me. I agree and already pointed out that it would not be a deterrent. Nowhere in my objective did deterrence come up.
You make some good points, points that are worthy of serious consideration for anyone attempting to implement this, but I would say that your points hardly make it impossible, in fact, they illustrate very well what a designer would need to consider! Thanks!

I never said that *anything* was impossible. I simply pointed out that IF the password was compiled into the bootloader, then THAT would be extremely dangerous since rather than trying out a tried and true bootloader, every change of password would be a serious brick-risk.
Regarding partition vs file, there is no difference. A partition *IS* a file in a very simple filesystem -- that which we refer to as a "partition table". As such, the risk is identical. I certainly did not suggest that a bootloader is incapable of reading a filesystem, the reverse is in fact, and MUST be true, since if the bootloader couldn't read the filesystem, then how is it to load something that is stored on said filesystem? The point is that if the filesystem were in some manner corrupted, overwritten, updated, etc., then so is your ability to boot the system PERMANENTLY, unless you maintain fastboot prior to the password, in which case it is trivial to boot off a different system image anyways, or unless you go to hardware level to unbrick the device, the same approach, of course, could be used by someone else to gain access.
Oh, and when you say "My personal threat model would assume that my data is less valuable to a thief than my phone is.", that suggests that your priorities are hardware first and then data.
I still say that the most feasible approach to this is selective encryption. Keep the important data from being accessed and not worry about the hardware, since there is no technical way to make it undesirable to a thief except, of course, to make it real ugly. Pack the thing into an old-style Palm case. Take a look into LUKS. It could *definitely* be made to work and is probably easier than you think. What you would have to do is first install support for it at the system level (that might require that you rebuild the kernel), encrypt a partition on the SDCARD with it, and link password, mount, and unmount into the lock screen. Once thats done, you just move and symlink important data onto the encrypted partition. For that matter, you don't even need to automate it with the lock screen, you can just write an app to password, mount, and unmount, or even run it from the terminal. Yes, this is just a linux device. This approach is barely more than trivial.

I never said that *anything* was impossible.
Click to expand...
Click to collapse
Sorry, the sentence below sounded like you were implying that it is was impossible.
No, bootloader password won't help you here, and I already explained why.
Click to expand...
Click to collapse
Oh, and when you say "My personal threat model would assume that my data is less valuable to a thief than my phone is.", that suggests that your priorities are hardware first and then data.
Click to expand...
Click to collapse
No, it suggests that those are the priorties of the thief. I don't believe a thief would steal my phone for its data. I accept that it can be stolen easily or that I might simply leave it on a table in a restaurant or something. At that point I would simply prefer that no one be able to easily snoop my personal affairs. Currently it is VERY easy. I had adb access to my phone before even using the screen, (I needed to register via wifi), it really is simple, it takes little expertise.
Regarding partition vs file, there is no difference. A partition *IS* a file in a very simple filesystem -- that which we refer to as a "partition table". As such, the risk is identical. I certainly did not suggest that a bootloader is incapable of reading a filesystem, the reverse is in fact, and MUST be true, since if the bootloader couldn't read the filesystem, then how is it to load something that is stored on said filesystem?
Click to expand...
Click to collapse
Call it what you will, I was giving you the benefit of the doubt.
Many bootloaders do not understand the filesystem they load from, they simply get a pre-created list of the disk blocks to load a kernel from and then load them and execute them.
The point is that if the filesystem were in some manner corrupted, overwritten, updated, etc., then so is your ability to boot the system PERMANENTLY, unless you maintain fastboot prior to the password, in which case it is trivial to boot off a different system image anyways, or unless you go to hardware level to unbrick the device, the same approach, of course, could be used by someone else to gain access.
Click to expand...
Click to collapse
For someone who seems to understand things well, you seem to willingly miss important points already mentioned:
With this you could reduce most "brick risk" by providing a "boot from external kernel for recovery after wiping the partitions" option.
Click to expand...
Click to collapse
You encryption points are well taken, they probably would be simple to implement, however they would likely have a significant performance impact.

MartinFick said:
You encryption points are well taken, they probably would be simple to implement, however they would likely have a significant performance impact.
Click to expand...
Click to collapse
Only if you're encrypting everything (i.e. programs). There is no reason to encrypt everything -- just encrypt the data you want to protect. There is no reason to bother encrypting apps that you install or the operating system since this is all available elsewhere. If you have private documents, emails, etc., keep those encrypted. The performance impact will be negligible since these files will be fairly small.

[Proof of Concept] Help for those who lost 4G

Apparently a number of folks lost their 4G keys. Kinda sucks when you are in a 4G market, and cannot take advantage since your 4G keys are hosed. Redsolar came up with a process for moving/editing your 4G key to a hobbled phone.
Further reading..
http://forum.xda-developers.com/showthread.php?t=716694
Some discussion made that once a phone is sent into either Sprint or Insurance for replacement the 4G keywould be rendered useless by Sprint. In a way I doubt that. It would be more prudent to invalidate the MAC address than the key. Since Wimax keys are generally used to en/decrypt the data. I believe that authentication fails because the network handshake is encrypted. But the initial connection is granted via the MAC address, then validation via the encrypted handshake. It would be easier to invalidate a MAC address than it is to do that with using the actual key (MAC=96 bits vs RAS key=2048). Hence smaller/faster hash table.
What I propose is that someone who has a rooted Evo that has either "lost", or severely damaged (but still accessable via USB by fastboot) their phone that will be going back to Insurance to pull their 4G key by redsolar's process. I in turn will hexedit the key to reflect my MAC address, load it on my borked phone, and see if once Sprint deactivates the phone donor if I would still have 4G. At that point we will know if Sprint is using the MAC address, or the actual key to allow/deny access to Wimax.
The thing is if it works it will have to be one donor key, to one borked phone. Redsolar already proved that two keys operating at the same time will not work. Maybe a repository? We have alot to gain and nothing to lose.
Anyone up for this?
Discuss.

I have a smashed evo that still can be accessed via ADB, even better, I never used 4G on it because at the time there was no 4G here. I am not sure about fastboot access at this time, but as I said ADB worked so I figure fastboot prolly does too. I work 48 hours this week, so not sure when I could try it.

SteelH said:
I have a smashed evo that still can be accessed via ADB, even better, I never used 4G on it because at the time there was no 4G here. I am not sure about fastboot access at this time, but as I said ADB worked so I figure fastboot prolly does too. I work 48 hours this week, so not sure when I could try it.
Click to expand...
Click to collapse
Awesome. If adb works so will fastboot, you just have to boot into bootloader.
Thanks!

That's easy enough then. I'll have to charge up a battery and go read that other post, unless you want to p[aste the commands I need to do in here.

Here you go!
1. Open command line window (cmd)
2. Make sure you have no PC36IMG.zip files in the root of your SD Card, or it will take a while to power your phone up
3. Power down your phone
4. Power it up while holding down the Volume Down key
5. HBOOT will attempt to scan for PC36IMG files. Let's hope you read carefully and don't have it on your SD Card root
6. Once HBOOT fails to find the file, use Vol Up/Down buttons to go into Fastboot mode
7. Connect the USB cable to your phone (and PC). You may have to install the USB drivers that come with Android SDK, but chances are if you are looking for this solution, you already have them installed and working
8. The FASTBOOT mode will switch to FASTBOOT USB (that's good)
9. Test your fastboot by typing "fastboot oem h" in command window you opened earlier (note, no adb, or adb shell anywhere, the command is "fastboot oem h". From here on all fastboot commands are issued in that window
10. If you see less than ~40 lines of output, you don't have a propertly rooted phone, and you need to do step 1 and step 2 (see above)
11. Dump your wimax data by issuing "fastboot oem saveprt2sd wimax -n wimax.bin" command (varies, anywhere between 7 to 8.5 MB, mine was 7MB)
12. Dump complete partition (~12MB) by issuing "fastboot oem saveprt2sd wimax -n wimax.bin -a" command
13. Reboot your phone
14. Pull the data files you dumped to a safe place ("adb pull /sdcard/WIMAX.BIN" and "adb pull /sdcard/WIMAXRAW.BIN"). Note the capitalization, it's important
PM me when you do it. I'll set up an account on my FTP box for you so you can upload it.

One major flaw to this attempt
0. The public/private keypair contains your phone's MAC address as part of your certificate's Common Name (CN), which is also most likely validated against the current mac on your phone
1 (corollary of 0). The phone must be an "activated and in service" phone for this to work. So if someone is keeping their broken paperweight and paying sprint the monthly fee for it - sure, this will work
2 (corollary of 1). Using a pair of keys from a deactivated phone will not allow you 4G access, sorry .
If through some miracle of Sprint's negligence the above is not true, I will tip my hat off to you
The negligence would mean that they are not checking anything but whether your public key is signed by HTC, and are happy with the actual MAC address that your phone provides them during authentication. That would be a major major flaw, since MAC address is so easy to change in fastboot.

If you read redsolar's thread, you'll see that I've tried this. It's worth it to try again, but for reference purposes, I have tried and failed.
Here's what I've tried:
I've cloned a friend's wimax certs, changed the mac to mine. It worked. Downfall, is that only one of us can be on 4G at a time. (There doesn't seem to be any checking of mac address vs wimax cert)
I actually purchased someone's wimax certs from a phone that is no longer in service, and changed the mac to mine. Didn't work. Flashed back my friend's certs, worked.
Conclusion, the certs are most likely blacklisted if the phone is not in service.

and cannot take advantage since your 4G keys are hosed.
Click to expand...
Click to collapse
Just curious as I no longer live in a 4G area. What causes this "hosing of keys"?

Most of us who lost it did it through a botched wimax update. It's believed to have originally been released by revoked and circulated for a while during the last Eclair update for evo (1.47)
When wimax was initially a pain to flash. It used a write_raw_image command which overwrote wimax partition and in most cases did so over the unrecoverable SSL key pair.
Sent from my PC36100 using XDA App

Hmmm.. I would be using my valid MAC address. Usually it is the MAC since like IP's only one can exist on a network. Though it is quite probable that Sprint's implementation of Wimax does do a key hash. From the original spec of Wimax, the MAC authentication is done first at connection, then an encrypted handshake follows. The only way to see that is by using a Service Monitor, and watch the transaction. But you can't see what happens after the encryption starts (but you can watch what goes on before and after). HTC can't recreate your Wimax keys because Verisign's algorithm uses a random seed generator. So even if you where to get the keys from both the proceeding, and post MAC addresses to do a compare the RSG would be different on all three keys. Verisign made it easy for makers of electronics that use key encryption, it's just a simple web interface that in the case of cellphone the engineer plugs in a starting MAC address, and the number of keys to produce, and the computer just spits them out to the flash table.
I'm still willing to try. Can't screw up my Wimax anymore than what it is.

redsolar said:
Most of us who lost it did it through a botched wimax update. It's believed to have originally been released by revoked and circulated for a while during the last Eclair update for evo (1.47)
When wimax was initially a pain to flash. It used a write_raw_image command which overwrote wimax partition and in most cases did so over the unrecoverable SSL key pair.
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
Very interesting. I lost mine on 1.47.651. Never used Unrevoke. Thats besides the point. I have a question which I'm sure I have asked before, but just want to make sure that the info I received was accurate.
I have backed up my Wimax partions (I have a wimax.bin that is around 8MB and another wimax.bin that is 12MB). If I ever lost or hosed my wimax, could I just push this partition backup onto the phone and I should get my wimax up and running again?
Thanks for any info!

wsantiagow said:
Very interesting. I lost mine on 1.47.651. Never used Unrevoke. Thats besides the point. I have a question which I'm sure I have asked before, but just want to make sure that the info I received was accurate.
I have backed up my Wimax partions (I have a wimax.bin that is around 8MB and another wimax.bin that is 12MB). If I ever lost or hosed my wimax, could I just push this partition backup onto the phone and I should get my wimax up and running again?
Thanks for any info!
Click to expand...
Click to collapse
If you followed redsolar's procedure, yes.

I would guess they are using a CRL (Certificate Revoked List) that is probably added once you deactivate the phone. I really hate that they didn't store the certs in a cert8.db and key3.db file on /system or something...

HTC Boot loader unlocking process (how it's probably done programatically)

I posted this on my website, and thought people here might also appreciate it:
So to start this off, this is not about how to unlock your HTC phones boot loader, it is about what we can infer about the process due to the way to works (for more information on the process, see this). From what it would appear this is some sort of hashing algorithm, upon first look it would most likely be a one way hash of the token passed to them at step 2. However there is also the possibility that this is RSA in reverse.
If it is a hashing algorithm, this seems to be a best case scenario. If it is a hashing algorithm, then each ID will have a different unlock code sent to them obviously. But the real question is how to phone will validate this. Does the phone have the unlock code programmed into the NAND, which would be a very nice solution if it just checks to see if the two codes match. Or does it just have the algorithm to hash the id built in and do that before checking it, which is another decent proposition as if a hacker could get there hand on that and reverse engineer they could set up a 3rd party boot loader unlocker.
If it is RSA in reverse it would actually be much simpler to break the code. We know that the phones processor can only do so much computation which would limit the possibilities for the key used to decrypt what is sent back from the HTC server. We also know that the key would have to be stored on the phone, even if it was just temporarily in order for the phone to be able to unlock the boot loader if that was the case, so it would lend the possibility that the user could dump the information in the NAND and get the decryption key. However unfortunately as we know that won’t help much with RSA as it uses two different keys to encrypt and decrypt, but it is an intriguing thought.
In conclusion there aren’t too many possibilities of how the boot loader is being unlocked by HTC, those are the only ones which I could think of that would fit (however there are likely many more). Thus because of the limited possibilities, it is only a matter of time until the process is reverse engineered allowing users to unlock their boot loader through non-official means, and if it is not able to be reverse engineered, I’d be willing to make a gentleman’s bet that at some point it will get leaked. If anyone would like to rebuttal and tell me why I’m dead wrong I would love to hear it. What are your thoughts on this?

Just a pointer, even with the phones limited processing power as long as its not trying to crack ,generating keys, or encrypting stuff, it would be very easy to use a very long key
Edit: there could also be a chip on the board that checks a hash on the bootloader, if the hash is different (think md5) the bootloader is not the same. However It would not prevent you from doing, rather it would prevent your phone from booting
Lol just shot my own idea out of the sky
Sent from my ADR6300 using XDA App

[HELP] Cannot factory reset a Kyocera Hydro Wave (C6740N) on Metro PCS

Greetings to all the developers and registered users on this site... Yes, this is my first post, but I read here pretty often and I used the search function, trust me! Seriously, I've tried all I could and I am at my wits end, but this is technology, we can't let it own us, we gotta continue owning it and that's what online communities like xda help us do, so thanks for all your past, present, and future contributions here. So I got this Metro PCS Kyocera Hydro Wave (C6740N) that I can't factory reset for a number of reasons, but mainly because I believe that there is either no boot-loader or no recovery partition as a result of Metro PCS flashing the ROM...
Anyway, lets get to the juice:
- Device powers on/off, but no combo of Vol -/+ and Power buttons bring up a recovery menu or anything (holding any combo down just boot-loops)
- Device has no SIM and no micro SD card, and the battery is not removable
- Device is locked... Like, pattern-locked/google account info/too many attempts/yada yada yada
- Device has no data and no WiFi connection active, so I could not use the google account to get past the lockscreen
- Device does not have USB debugging enabled/Google drivers for ADB do not work (Windows 7 auto-detects when I plug in the phone and installs a generic Microsoft driver which cannot be removed even after uninstalling the device, and also I pointed the Device Manager to the correct Google drivers I installed with the Android SDK Tools, as well as the Samsung Naked Universal Drivers I found on this forum, and Kyocera ADB drivers I found through Google which all failed, Windows returned a message stating that the most up-to-date or best driver for this device is already installed)
What I've tried (everything possible really):
- Hard reset/Recovery from phone: FAILED
- Connect to Linux and install ADB, then tried running the adb shell, adb devices, fastboot devices, etc but phone not detected: FAILED
- Connect to Windows 7 and install ADB (Android SDK Tools), I literally checked every single box and installed Platform-tools, google drivers, everything, got to the command prompt as admin, cd to the ADB directory, ran same commands as in linux, also tried commands on several forums and posts like adb shell rm /data/system/gesture.key to remove the lock but everything: FAILED
- Connect to Windows 7 and attempt to install proper drivers using RootGenius, MoboRobo, PDAnet, and several other suggestions which all were oblivious/unable to detect the device despite Windows recognizing it, so they all: FAILED
- Connect to Windows 7 and attempt running ADB through a Cygwin terminal, but the command "sudo" was not recognized/not valid, so: FAILED
- Connect to Windows 7 and use XRYViewer to extract data from the phone, possibly to see the system files and get an actual understanding of what everybody is saying you need to mount from the recovery partition, but no clue how to use this, since I can't find an XRY file in the internal storage, so: FAILED
- Connect to Windows 7 and access data/recover data from device using "Wondershare Dr.Fone for Android" and "iLike Android Data Recovery Pro" but both programs instructed me to enable USB Debugging, which is not possible, so the both also: FAILED
Despite this being my first post, I have scoured the forums here in addition to every other forum and webpage regarding this issue as well... There just isn't much about this phone except negative reviews, and I have come to the conclusion that on this particular model phone, I am out of options... I have a paperweight... I'm not very familiar with Android... So please correct me if I'm wrong...

Any input?
I'm curious if there are any options at this point, I have been trying to get through to this phone on several computers for the past couple days and it is frustrating me... Any input from the community would be much appreciated...

Mojo2XL, I guess you did not find an answer?
Mojo2XL said:
I'm curious if there are any options at this point, I have been trying to get through to this phone on several computers for the past couple days and it is frustrating me... Any input from the community would be much appreciated...
Click to expand...
Click to collapse
I have the exact same problem and it appears I am several months after your post. I just want to use this device as an e-reader but like you, I cannot get anything to recognize it!~

eenuckols said:
I have the exact same problem and it appears I am several months after your post. I just want to use this device as an e-reader but like you, I cannot get anything to recognize it!~
Click to expand...
Click to collapse
may be this:
*2767*3855# - Think before you give this code. This code is used for factory format. It'll remove all files and settings including the internal memory storage. It'll also reinstall the phone firmware.
I found code in internet, but may be it works? can't check, my "wave" comes to me from USA by post for a few weeks..

barabeka said:
may be this:
*2767*3855# - Think before you give this code. This code is used for factory format. It'll remove all files and settings including the internal memory storage. It'll also reinstall the phone firmware.
I found code in internet, but may be it works? can't check, my "wave" comes to me from USA by post for a few weeks..
Click to expand...
Click to collapse
doesnt work.. you can only get to emergency dialer which can only b used to make emergency calls

elliwigy said:
doesnt work.. you can only get to emergency dialer which can only b used to make emergency calls
Click to expand...
Click to collapse
okay. i will try something, when my phone will come. is your Wave locked?

barabeka said:
okay. i will try something, when my phone will come. is your Wave locked?
Click to expand...
Click to collapse
i bought another phone and they threw it in free but it has a pin code lock so i cant even get to google screen to bypass frp as im stuck at pin lockscreen and these darnphones have no recovery..
i doubt ull figure out a way as im real savvy with this stuff lol theres no recovery to boot into in order to reset and no way to update tje phone wothout knowing the pin code

any luck? i cant believe this thing is this locked down. makes apple look like chils play

warriorpluto said:
any luck? i cant believe this thing is this locked down. makes apple look like chils play
Click to expand...
Click to collapse
i believe it can be done with a pc

Did you happen to get the files the other member posted that was only available for eight days?

Mojo2XL - Sort of.
I saw a youtub video (sorry no link) that says there was a OTA update that changed the phone's firmware that solved all the problems mentioned here. Thing is I have no carrier and cannot find this new firmware, but, I am still hunting....
​
eenuckols said:
I have the exact same problem and it appears I am several months after your post. I just want to use this device as an e-reader but like you, I cannot get anything to recognize it!~
Click to expand...
Click to collapse

I'm having the same problem, I have been trying to get this thing to hard reset for a week now. There has to be a way to reset this Hydro Wave.. Has anyone dealt with this thing?

Hey hold the buttons as follows volume- & power at the exact same time while your phone is off be warned if you phone was preowned you need the goole account originally activeated with that phone if you do not have that then your in the same vote as me i cant remember any of my gmail account info to my wave from when i had it active I have litterally tried every thing to recover the info and i still can't recover it

WhiteWolf77 said:
Hey hold the buttons as follows volume- & power at the exact same time while your phone is off be warned if you phone was preowned you need the goole account originally activeated with that phone if you do not have that then your in the same vote as me i cant remember any of my gmail account info to my wave from when i had it active I have litterally tried every thing to recover the info and i still can't recover it
Click to expand...
Click to collapse
That doesn't work on this phone the hydro wave from AT&T has factory reset protection so it cannot be reset using the volume down and power button reset

Any update?

dannybz said:
Any update?
Click to expand...
Click to collapse
let me work on this, been trying to master as many FRP bypasses as i can. I don't have the device but a client is in the same boat

I accidentally stumbled upon a something weird. I've managed to make the camera crash to the home screen somehow. I believe this was a result of holding both volume buttons and opening numerous menus while using the camera. My guess is that it overloads it after a certain amount of times and causes it to crash. I've gotten the android UI to crash like this before. I will try to recreate the scenario and update you guys on this. it's on a Kyocera Hydro Wave. Running android 5.0 I believe. Try going wild until the phone starts to lag. eventually stuff will crash and the lock screen may go with it. use this to your advantage and enable USB debugging as quickly as possible because it will reset itself after about 30 seconds. Someone else on YouTube has recently told me that it worked for them. I would look into doing that.

PhoneScrambler said:
I accidentally stumbled upon a something weird. I've managed to make the camera crash to the home screen somehow. I believe this was a result of holding both volume buttons and opening numerous menus while using the camera. My guess is that it overloads it after a certain amount of times and causes it to crash. I've gotten the android UI to crash like this before. I will try to recreate the scenario and update you guys on this. it's on a Kyocera Hydro Wave. Running android 5.0 I believe. Try going wild until the phone starts to lag. eventually stuff will crash and the lock screen may go with it. use this to your advantage and enable USB debugging as quickly as possible because it will reset itself after about 30 seconds. Someone else on YouTube has recently told me that it worked for them. I would look into doing that.
Click to expand...
Click to collapse
Is there anything a little more realistic possible? Lol, I can see an update available, can't connect to WiFi to update haha. The stuff they lock these phones with anymore i swear

I'm new to this forum, but NOT new to this site . I have visited here on numerous occasions seeking the help that needed . With that being said, I would like to offer a Bonafide, Tried and True way to factory reset the Kyocera Hydrowave . I KNOW that this work's for I have done in on numerous occasions for a friend of mine that works for Metro PCS ....
Step One: Completely power off the phone .
Step Two: Hold the Power AND Volume DOWN Buttons SIMULTANEOUSLY .
Step Three: DO NOT release any buttons, even when you get to the Boot Menu . (Very Important, If you don't do it right, you have to start all over lol ) .
Step Four: Once inside the Boot Menu, ONLY release the Power Button; or the Boot Menu will close and you have to start all over again .
Step Five: Use the Volume Down Button to Highlight the Wipe/Factory Reset Option .
Step Six: Use the Power Button to Select the option .
Step Seven: Watch the bottom of the screen for the progress, and then use the Volume Up Button to restart .
And there you have it . I hope that this helps out SOMEONE out there, because I feel good giving back for the help that I have received on here .
PS.( If you would like for me to post a Video Tutorial on this, can someone please tell me how to post the Video; I guess by me being a Newbie on here, I'm not allowed to do as of yet ) . If Anyone needs to contact me, as I'm not on here very often, my email is [email protected] .

LilAnt530 said:
Is there anything a little more realistic possible? Lol, I can see an update available, can't connect to WiFi to update haha. The stuff they lock these phones with anymore i swear
Click to expand...
Click to collapse
As unrealistic as it may sound it actually works Trust me on this. its similar to the LG attack which... is nothing but entering a long password.
betanews.com/2015/09/16/bypass-the-android-lollipop-lockscreen-by-entering-a-really-long-password
Just give it a go. it already worked for one dude on youtube. it takes a while but it honestly works. If you can get it, update the phone as soon as possible turn the screen timeout off and let it update. when the phone resets the update will install and you will be able to factory reset.
I mean it couldn't hurt. if you're locked out with no factory reset and ADB tools won't work what else can you do?

Pin locked; TWRP flashing not allowed in locked state; need to recover data

Hello - I have a rather unique situation and have been searching for possible solutions since last few days. I have forgotten my pin or potentially an update or my office apps have locked my phone. I have it connected using fastboot to my PC however I am not able to flash TWRP as it gives an error: Flashing not allowed in Lock State. Is there any way for me to back up the data before doing a reset? Is there any code which can be used to bruteforce different pin combinations in recovery mode / fastboot mode? Any help is greatly appreciated. I have the output of "fastboot getvar all" in case that can help you locate the partition to boot/erase. thanks a ton!

Oneplus8TPinFinder said:
Hello - I have a rather unique situation and have been searching for possible solutions since last few days. I have forgotten my pin or potentially an update or my office apps have locked my phone. I have it connected using fastboot to my PC however I am not able to flash TWRP as it gives an error: Flashing not allowed in Lock State. Is there any way for me to back up the data before doing a reset? Is there any code which can be used to bruteforce different pin combinations in recovery mode / fastboot mode? Any help is greatly appreciated. I have the output of "fastboot getvar all" in case that can help you locate the partition to boot/erase. thanks a ton!
Click to expand...
Click to collapse
In what way are you phone locked? I don't think there are anything you can do to save your data if you don't know your password/pin. TWRP wouldn't have helped in this case either.

Hi - thanks for your reply. My pin is not working and every pin trial is taking quite a bit of time. I am able to try pins quickly in recovery mode but trying all possible 4 digit combinations will take quite a bit of time. Alternatively, a brute force code to keep trying different pins would also be beneficial if you are aware of it.
Wont adb would have let me back up my phone data?

No way to bruteforce it that I am aware off.
your pin is needed to decrypt the encryption key that is used to decrypt data. So you can't access or backup any data without your pin. This is by design.

But cant the encryption key be overwritten using my biometrics which I have registered as well? Or something that manufacturer can do because there are tonnes of solutions for samsung and lg devices but am struggling to find something for oneplus..

Oneplus8TPinFinder said:
But cant the encryption key be overwritten using my biometrics which I have registered as well? Or something that manufacturer can do because there are tonnes of solutions for samsung and lg devices but am struggling to find something for oneplus..
Click to expand...
Click to collapse
Perhaps this is because OnePlus has properly secured their devices and Samsung/LG hasn't? Though I do contest that statement. By my knowledge all devices perform a data wipe when the bootloader is unlocked (aside from one OP device that had a flaw in this area IIRC).
Please view this from another perspective: if your device was stolen and you've PIN protected it, would you want the thief to be able to unlock it and view all your pictures/videos/documents/etc?

Timmmmaaahh! said:
Perhaps this is because OnePlus has properly secured their devices and Samsung/LG hasn't? Though I do contest that statement. By my knowledge all devices perform a data wipe when the bootloader is unlocked (aside from one OP device that had a flaw in this area IIRC).
Please view this from another perspective: if your device was stolen and you've PIN protected it, would you want the thief to be able to unlock it and view all your pictures/videos/documents/etc?
Click to expand...
Click to collapse
I agree but one pin cant and should not be the only way to unlock phone. In my particular case, I have now started to think that some of the app has messed up with the pin or an android update has messed up with the pin. I am quite surprised that a forgot pin / pattern option doesnt even come as if no one can forget pin. Is there a way to hack into my phone given I am logged into same gmail and other apps as I am logged into my new realme phone?

Oneplus8TPinFinder said:
I agree but one pin cant and should not be the only way to unlock phone. In my particular case, I have now started to think that some of the app has messed up with the pin or an android update has messed up with the pin. I am quite surprised that a forgot pin / pattern option doesnt even come as if no one can forget pin. Is there a way to hack into my phone given I am logged into same gmail and other apps as I am logged into my new realme phone?
Click to expand...
Click to collapse
First time I've heard of a failing PIN, let alone an app that would mess with it (which is absolutely impossible). Asking for a hack into your phone is asking for an illegal way to access your device, which crosses a boundary we will not get into on this platform. We tweak devices, we add functionality, we use exploits to alter the aesthetics of a device and we surely mess them up a lot but we will not support anything beyond our terms.
But! If there indeed is an issue with the OnePlus 8T PIN security, I hope people will report it here. AFAIK there is no such issue widely known.
I also hope it's a lesson in creating proper backups. I guess learning the hard way is the best way. I think we've all been there. I sure have!

you could reset it and enter email registered with that device they fix or email you code to fix