Bypass secure USB debugging prompt on phone with broken screen
- Thread starter maq_
- Start date
. Have you been able run this tutorial successfully?
Renate
Recognized Contributor / Inactive Recognized Dev
The original post talks about how to do this using methods that are no longer readily applicable.
There are at leastfour five basic ways to "authorize":
If the touch part of the screen is working, that's a plus, but getting anything to work poking blind is difficult.
Using an USB OTG mouse to enable a Bluetooth mouse to authorize the ADB popup is also a challenge.
Depending on Android version mounting /data in recovery and modifying is probably not possible.
Modifying /system in recovery also runs into problems with dm-verity, AVB.
Modifying a boot image and flashing it is possible if you deal with dm-verity, AVB.
Depending on your recovery, you might need low-level tools (like EDL) to pull a copy of your boot image.
In Windows it's C:\Users\Username\.android\adbkey.pub
This is the public key (i.e. non-secret) and is around 700 bytes.
The best advice is to always have ADB on, always have ro.adb.secure=1 (for security) and to make sure that your device is authorized on a desktop or two.
Also, backing things up is not a bad idea.
There are at least
- click authorize on the ADB popup
- change ro.adb.secure to 0 in prop.default
- replace adbd with a patched version that doesn't require authentication ever
- add your public key to /data/misc/adb/adb_keys
- add your public key to /adb_keys (easy to do with a ramdisk)
If the touch part of the screen is working, that's a plus, but getting anything to work poking blind is difficult.
Using an USB OTG mouse to enable a Bluetooth mouse to authorize the ADB popup is also a challenge.
Depending on Android version mounting /data in recovery and modifying is probably not possible.
Modifying /system in recovery also runs into problems with dm-verity, AVB.
Modifying a boot image and flashing it is possible if you deal with dm-verity, AVB.
Depending on your recovery, you might need low-level tools (like EDL) to pull a copy of your boot image.
You don't need to do that. The public key is already on your desktop.
In Windows it's C:\Users\Username\.android\adbkey.pub
This is the public key (i.e. non-secret) and is around 700 bytes.
The best advice is to always have ADB on, always have ro.adb.secure=1 (for security) and to make sure that your device is authorized on a desktop or two.
Also, backing things up is not a bad idea.
Last edited:
So basically there is no hope there. Because my device is an sm-j530 Samsung and it has no screen attached, I had to remove it since it was shattered. Unless you know some android OTG hotkeys to turn on mobile data?
Renate
Recognized Contributor / Inactive Recognized Dev
Are you using Magisk already? Or does your boot image have a ramdisk?
I don't love/use/know anything about Samsung devices. Can you replace the boot image without the device exploding?
If you can replace your boot image and you already have or can add ramdisk you just need to add adb_keys in /
(I edited the post above to mention that.)
I don't love/use/know anything about Samsung devices. Can you replace the boot image without the device exploding?
If you can replace your boot image and you already have or can add ramdisk you just need to add adb_keys in /
(I edited the post above to mention that.)
Renate
Recognized Contributor / Inactive Recognized Dev
Are you sure that your device has no video output over the USB connector MHL/DP/HDMI capability?
Using OTG, a hub, a keyboard and a mouse would be a challenge.
Still, at least with a keyboard navigating with arrows would be less problematic than a mouse.
Actually, a digitizing tablet would be good as it's absolute and not relative like a mouse.
If you had an identical device to use as reference it might not be too bad.
Just put down a piece of paper and mark it and use it as reference.
You could also borrow a screen from somebody/somewhere. You don't need to unglue the old one, just connect the new one with it loose.
Using OTG, a hub, a keyboard and a mouse would be a challenge.
Still, at least with a keyboard navigating with arrows would be less problematic than a mouse.
Actually, a digitizing tablet would be good as it's absolute and not relative like a mouse.
If you had an identical device to use as reference it might not be too bad.
Just put down a piece of paper and mark it and use it as reference.
You could also borrow a screen from somebody/somewhere. You don't need to unglue the old one, just connect the new one with it loose.
Any chance we could connect and have chat sometime? then I could show you my device
No, you don't need file for QMobile Noir. You have to make your own file with AIK (refer to post #14 + #8)
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
8Solved!
This guide assumes that USB debugging was enabled on your device before you broke it. You can enable USB debugging via recovery using:
Code:adb shell echo "persist.service.adb.enable=1" >>/system/build.prop echo "persist.service.debuggable=1" >>/system/build.prop echo "persist.sys.usb.config=mass_storage,adb" >>/system/build.prop" reboot
After digging through various threads I finally managed to bypass the secure USB prompt on my Galaxy SII with a shattered screen.
For this method to work you need another device running Android 4.4.2 or above with USB debugging enabled and the same computer authorised from that device i.e. connect that device to your computer and press "OK" on the authorisation prompt that appears on screen for secure USB debugging. Let us call this device the "authorised device".
"adb_keys" is the file we need from the authorised device which is located in /data/misc/adb/
Normally you must be rooted to take the adb_keys file from the device using "Root explorer" or "ES File Explorer" but I will assume that the authorised device is unrooted. You don't need to root it. However, if your authorised device is rooted then simply copy the adb_keys file on your computer and jump directly to Step 5.
Steps:
- Connect the authorised device to your computer using USB (debugging enabled) and open a command prompt with administrator privileges.
- To get the "adb_keys" file, use this command:
- adb pull /data/misc/adb/adb_keys <destination path>/adb_keys
- For example:
- adb pull /data/misc/adb/adb_keys c:/adb_keys
- The above command will save the adb_keys file to the root of your C: drive. You can change the destination folder to your liking. Now the job of the authorised device is done. You can disconnect it and disable USB debugging.
- Once you get a copy of adb_keys, reboot the phone with the broken screen into recovery.
- Now connect the broken phone to the computer using USB.
- We need to copy the adb_keys file to the broken device. Use the command below:
- adb push <file location> /data/misc/adb
- For example:
- adb push c:/adb_keys /data/misc/adb
- After the file is copied, reboot your device using "adb reboot" and voila! You can now use adb shell.
Check out this thread by k.janku1 if you want to have full control over your device even with a broken screen (requires Java Runtime Environment and Visual C++ redistributable). This tool lets you use your device through your Windows PC even if your touchscreen doesn't work or you can't see anything.
P.S.: My broken device was a Samsung Galaxy SII running Cyanogenmod 11 (M12) and my authorised device was an unrooted Moto G running stock ROM.2Thanks for clarifying TWRP and UNLOCKED bootloader is required.
TWRP is not available for some devices. Luckily i found a ported recovery.img for my broken tablet. Unfortunately adb shows device as offline in TWRP, adb does not work in recovery.
I finally managed installing adbkey.pub via script. does not work on dm-verity, KNOX enabled or locked devices!
1. install ODIN (Samsung) or SPFLASH tool (MTK)
2. get the firmware for your device (fw.updato.com)
3. unpack system.img
4. add your own shell script (backdoor) to /system/etc/init.d, /system/etc/install-recovery.sh or whatever
5. repack your custom system.img
6. flash system.img
7. copy RSA Key to /sdcard via MTP
My (backdoor) shell script was a watchdog looking for another shell script on /sdcard. The second shell script was copying adbkey.pub from /sdcard to /data partition. This worked without root because init scripts run with root permissions on boot.
With this method i was able to backup userdata from my broken tablet via adb. TWRP has adb backup option too, in case touch screen is broken.
I will explain in detail on request.
edit: for experts only: instead of flashing whole system.img, you can do slight modification using Tarek Galal inception Utility via ODIN, for example "Place your adb keys, configure USB debugging"
edit2: most recent version of that backdoor script can be found here
https://forum.xda-developers.com/showthread.php?t=41119232I solved the problem by adding following script in userinit.sh:
Bash:# Waiting to copleted RSA_copy script (copying the public keys) sleep 30 # Enables the Developer Mode settings put global development_settings_enabled 0 sleep 5 settings put global development_settings_enabled 1 sleep 5 # Enables the USB Debugging settings put global adb_enabled 0 sleep 5 settings put global adb_enabled 1
I do hope it will work for the others finding the solution
Once again thanks @aIecxs1I too am a noob who was trying to follow this guide, which also exactly fit my situation. My status was a broken Sony Xperia screen with USB debugging enabled, but I was unable to click on the "accept" button whenever I hooked my phone up to my PC. I extracted a working adb_key from my new Asus ZooXS phone; neither phone is rooted, and both are running stock Android OS.
Unfortunately, I got stuck right between Steps 7 & 8; Windows did not allow me to use the ADB Push command to copy the key onto my broken Sony Xperia. I could Pull the key from my Asus using ADB just fine, but not the other way around.
I did eventually find an alternative solution: I used an OTG device & hooked up a mouse to my Sony Xperia so that I could get past the broken screen issues & navigate to Settings > Bluetooth. I then borrowed a Bluetooth Mouse & "discovered" it with my broken Sony Xperia. I could then unplug the OTG device & re-connect my phone to my PC via USB, & then click on the screen using the Bluetooth Mouse to "accept" my computer as always being authorized to perform USB debugging. Afterwards, I was able to use Helium backup to pull off most of my important data from my phone.
Hope this helps others who are running into the same problem....1The original post talks about how to do this using methods that are no longer readily applicable.
There are at leastfourfive basic ways to "authorize":
- click authorize on the ADB popup
- change ro.adb.secure to 0 in prop.default
- replace adbd with a patched version that doesn't require authentication ever
- add your public key to /data/misc/adb/adb_keys
- add your public key to /adb_keys (easy to do with a ramdisk)
If the touch part of the screen is working, that's a plus, but getting anything to work poking blind is difficult.
Using an USB OTG mouse to enable a Bluetooth mouse to authorize the ADB popup is also a challenge.
Depending on Android version mounting /data in recovery and modifying is probably not possible.
Modifying /system in recovery also runs into problems with dm-verity, AVB.
Modifying a boot image and flashing it is possible if you deal with dm-verity, AVB.
Depending on your recovery, you might need low-level tools (like EDL) to pull a copy of your boot image.
You don't need to do that. The public key is already on your desktop.
In Windows it's C:\Users\Username\.android\adbkey.pub
This is the public key (i.e. non-secret) and is around 700 bytes.
The best advice is to always have ADB on, always have ro.adb.secure=1 (for security) and to make sure that your device is authorized on a desktop or two.
Also, backing things up is not a bad idea.
