Bypass secure USB debugging prompt on phone with broken screen

Search This thread

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 least four five basic ways to "authorize":
  1. click authorize on the ADB popup
  2. change ro.adb.secure to 0 in prop.default
  3. replace adbd with a patched version that doesn't require authentication ever
  4. add your public key to /data/misc/adb/adb_keys
  5. add your public key to /adb_keys (easy to do with a ramdisk)
All of these run into some "Catch 22" as they would all be easier with ADB running.

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.

adb is used on an authorized device to capture its adb keys.
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:
  • Like
Reactions: aIecxs

EWill9

Member
Sep 5, 2022
9
0
The original post talks about how to do this using methods that are no longer readily applicable.
There are at least four basic ways to "authorize":
  1. click authorize on the ADB popup
  2. change ro.adb.secure to 0 in prop.default
  3. replace adbd with a patched version that doesn't require authentication ever
  4. add your public key to /data/misc/adb/adb_keys
All of these run into some "Catch 22" as they would all be easier with ADB running.

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.
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.)
 

EWill9

Member
Sep 5, 2022
9
0
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 have any of those unfortunately. Wish there was a way to my stuff.
 

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.
 

EWill9

Member
Sep 5, 2022
9
0
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.
Any chance we could connect and have chat sometime? then I could show you my device
 

alfanveykov

Member
Oct 20, 2018
25
2
I 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 @aIecxs
Please how to do it, after flash zip, my phone bootloop,
 

alfanveykov

Member
Oct 20, 2018
25
2
Warning! insecure! use for temporary access on broken screen only
- added /sbin/99userinit_daemon
- modified default.prop
- modified init.rc

boot image from fastboot (or flash with SP Flash Tool)
Code:
fastboot boot <file>

Only in case adb still not working:

copy your PC's adbkey.pub to phone. check rsa_copy.log for info about success. reboot phone

(attachment removed)
why the file is removed, i need it brother
 

Top Liked Posts

  • There are no posts matching your filters.
  • 8
    Solved!

    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:

    1. Connect the authorised device to your computer using USB (debugging enabled) and open a command prompt with administrator privileges.
    2. 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
    3. 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.
    4. Once you get a copy of adb_keys, reboot the phone with the broken screen into recovery.
    5. Now connect the broken phone to the computer using USB.
    6. 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
    7. After the file is copied, reboot your device using "adb reboot" and voila! You can now use adb shell.
    Special thanks to torankusu for this post which helped me compile this guide.


    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.
    2
    Thanks 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=4111923
    2
    I 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 @aIecxs
    1
    I 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....
    1
    The original post talks about how to do this using methods that are no longer readily applicable.
    There are at least four five basic ways to "authorize":
    1. click authorize on the ADB popup
    2. change ro.adb.secure to 0 in prop.default
    3. replace adbd with a patched version that doesn't require authentication ever
    4. add your public key to /data/misc/adb/adb_keys
    5. add your public key to /adb_keys (easy to do with a ramdisk)
    All of these run into some "Catch 22" as they would all be easier with ADB running.

    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.

    adb is used on an authorized device to capture its adb keys.
    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.