[Onetouch Idol 3 Q&A, Help & Troubleshooting] famewolf:
Does the sha1 sum of your recovery happen to match f9062580503eb61b315a5d12c5c6b3bb133aa4b2 ? If so it could solve some issues but why do I suddenly think all 3 models have their own recovery?

---------- Post added at 08:47 AM ---------- Previous post was at 08:43 AM ----------

adb reboot bootloader won't work even with it showing unauthorized? If you can get into bootloader you can fix /system without messing up your /data (don't wipe data or you lose adb entirely...you may figure out how to add the correct hash if we can find how it's generated)

Here's some info on the hashes you might find useful taken from: http://nelenkov.blogspot.com/2013/02/secure-usb-debugging-in-android-422.html

Secure ADB implementation

The ADB host authentication functionality is enabled by default when the ro.adb.secure system property is set to 1, and there is no way to disable it via the system settings interface (which is a good thing). The device is initially in the OFFLINE state and only goes into the ONLINE state once the host has authenticated. As you may already know, hosts use RSA keys in order to authenticate to the ADB daemon on the device. Authentication is typically a three step process:

After a host tries to connect, the device sends and AUTH message of type TOKEN that includes a 20 byte random value (read from /dev/urandom).

The host responds with a SIGNATURE packet that includes a SHA1withRSA signature of the random token with one of its private keys.

The device tries to verify the received signature, and if signature verification succeeds, it responds with a CONNECT message and goes into the ONLINE state. If verification fails, either because the signature value doesn't match or because there is no corresponding public key to verify with, the device sends another AUTH TOKEN with a new random value, so that the host can try authenticating again (slowing down if the number of failures goes over a certain threshold).

Signature verification typically fails the first time you connect the device to a new host because it doesn't yet have the host key. In that case the host sends its public key in an AUTH RSAPUBLICKEY message. The device takes the MD5 hash of that key and displays it in the 'Allow USB debugging' confirmation dialog. Since adbd is a native daemon, the key needs to be passed to the main Android OS. This is accomplished by simply writing the key to a local socket (aptly named, 'adbd'). When you enable ADB debugging from the developer settings screen, a thread that listens to the 'adbd' socket is started. When it receives a message starting with "PK" it treats it as a public key, parses it, calculates the MD5 hash and displays the confirmation dialog (an activity actually, part of the SystemUI package). If you tap 'OK', it sends a simple simple "OK" response and adbd uses the key to verify the authentication message (otherwise it just stays offline). In case you check the 'Always allow from this computer' checkbox, the public key is written to disk and automatically used for signature verification the next time you connect to the same host. The allow/deny debugging functionality, along with starting/stopping the adbd daemon, is exposed as public methods of the UsbDeviceManager system service.

We've described the ADB authentication protocol in some detail, but haven't said much about the actual keys used in the process. Those are 2048-bit RSA keys and are generated by the local ADB server. They are typically stored in $HOME/.android as adbkey and adbkey.pub. On Windows that usually translates to %USERPOFILE%\.android, but keys might end up in C:\Windows\System32\config\systemprofile\.android in some cases (see issue 49465). The default key directory can be overridden by setting the ANDROID_SDK_HOME environment variable. If the ADB_VENDOR_KEYS environment variable is set, the directory it points to is also searched for keys. If no keys are found in any of the above locations, a new key pair is generated and saved. On the device, keys are stored in the /data/misc/adb/adb_keys file, and new authorized keys are appended to the same file as you accept them. Read-only 'vendor keys' are stored in the /adb_keys file, but it doesn't seem to exist on current Nexus devices. The private key is in standard OpenSSL PEM format, while the public one consists of the Base 64 encoded key followed by a `user@host` user identifier, separated by space. The user identifier doesn't seem to be used at the moment and is only meaningful on Unix-based OS'es, on Windows it is always 'unknown@unknown'.

While the USB debugging confirmation dialog helpfully displays a key fingerprint to let you verify you are connected to the expected host, the adb client doesn't have a handy command to print the fingerprint of the host key. You might think that there is little room for confusion: after all there is only one cable plugged to a single machine, but if you are running a couple of VMs, thing can get a little fuzzy. Here's one of way of displaying the host key's fingerprint in the same format the confirmation dialog uses (run in $HOME/.android or specify the full path to the public key file):

awk '{print $1}' < adbkey.pub|openssl base64 -A -d -a \

|openssl md5 -c|awk '{print $2}'|tr '[:lower:]' '[:upper:]'

We've reviewed how secure ADB debugging is implemented and have shown why it is needed, but just to show that all of this solves a real problem, we'll finish off with a screenshot of what a failed ADB attack against an 4.2.2 device from another Android device looks like: