Broken Screen No Touch: Extracting Data With OTG, scrcpy and ISP

🔒 This article is maintained by PhoneRepair.biz's automated research assistant and checked against public sources. Last reviewed: 2026-07-01. Spotted a mistake? Report an error on the talk page — or just edit the article. Suggestions from readers are reviewed before going live.

Recovery at a glance
Difficulty	Advanced (software methods: Intermediate; ISP/chip-level: Expert)
Risk to data	Low for OTG/scrcpy; High for ISP micro-soldering
Time estimate	15 minutes (OTG) to several hours (ISP)
Storage type	eMMC / UFS
Device state	Powered, storage intact; ideally AFU with USB debugging authorised
Key tools	OTG adapter, USB mouse/keyboard, PC with scrcpy + ADB, EDL/BROM cable, ISP programmer (UFI/EasyJTAG/Medusa), microscope, soldering station

A phone with a working display but a dead digitiser — or a dead display with intact storage — is one of the most common data-recovery jobs in the shop. This article walks through a tiered approach, from the least invasive (software control over USB) to the most invasive (in-system programming of the flash chip). The single most important truth to internalise up front: on any modern, encrypted handset, getting the bytes off the chip is the easy part — turning ciphertext back into usable files is the part that encryption is specifically designed to make impossible without the user's credential. Choose the lowest tier that will actually return usable data, and never solder when a US$5 OTG adapter would have done the job.

Overview

There are two independent failure modes that people lump together as "broken screen":

Display works, touch dead (cracked/failed digitiser, but you can still see the image). Here you only need an alternate input method — an OTG mouse plugged straight into the phone, or scrcpy over USB.
Display dead / black, touch unknown (backlight, panel, or connector failure). Here you need to control the device blind, either by mirroring to a PC (requires prior USB-debugging authorisation) or by driving it via HID with no visual feedback.

The recovery ladder, cheapest and safest first:

OTG mouse/keyboard plugged directly into the phone (display must work).
scrcpy over ADB — full screen mirroring + control on a PC (requires USB debugging already enabled and authorised).
scrcpy OTG mode — HID keyboard/mouse with no screen mirror, to blindly enable USB debugging or authenticate.
Logical/backup extraction via ADB once you have control (adb pull, adb backup, or vendor backup).
Chip-level imaging — Qualcomm EDL/Firehose, MediaTek BROM/Preloader (mtkclient), or ISP (in-system programming) directly on the eMMC/UFS test points. Produces a raw image — subject to the encryption reality below.

This is a procedure for devices you own or are lawfully authorised to service. None of the steps here are intended to defeat anti-theft protection (see #Legal and consent note).

Applies to

Dimension	Coverage
Brands / models	Android handsets and tablets broadly. Method availability is SoC-dependent, not brand-dependent.
SoC	Qualcomm (EDL/Sahara/Firehose), MediaTek (BROM/Preloader via mtkclient), Unisoc/Spreadtrum (SPD tools, less universal). Exynos/Kirin/Tensor have their own, more restrictive low-level modes.
Storage	eMMC (ISP-friendly: standardised CLK/CMD/DAT0 bus) and UFS (ISP is far harder — differential serial lanes, rarely broken out to friendly pads).
OS & encryption	Android 7+ almost universally FBE (File-Based Encryption); older/some low-end devices FDE (Full-Disk Encryption). Hardware-bound keys (Keymaster/StrongBox/TEE).
Required device state	Storage physically intact and the SoC bootable. Best case: AFU (After First Unlock) with USB debugging previously enabled and the host key authorised. Worst case for data: BFU (Before First Unlock) after a reboot — user data is inaccessible.
iPhone / iOS	Largely out of scope — see #Success rate and limitations. scrcpy and OTG HID do not work on iOS; SEP-bound encryption makes chip-level decryption infeasible. The realistic path is display replacement, covered in iPhone Screen Replacement for Data Recovery.

Risk to data

OTG mouse / scrcpy (Tiers 1–4): essentially zero risk to stored data. You are only sending input events. The device is never rewritten. This is why they are always tried first.
point of no return #1 — factory reset / "Repair Mode". Do NOT let the phone enter Samsung Repair Mode, a "reset to fix", or any setup-wizard "erase" path while flailing blindly. These wipe user data and, because keys are destroyed, the data is permanently unrecoverable. Community reports of exactly this loss during blind scrcpy navigation are common. When driving the screen blind, know the menu layout in advance.
point of no return #2 — a reboot into BFU. On an FBE device that was AFU (unlocked at least once since boot), the credential-encrypted keys live in RAM. A reboot flushes them. After reboot you are in BFU and cannot decrypt user data without the passcode. If the phone is currently powered and was unlocked since last boot, do not reboot it until you have extracted what you need.
EDL/BROM/ISP imaging is read-only when done correctly, but the setup is risky: wrong ISP wiring, over-voltage, or a slipped probe can kill the eMMC/CPU; a bad Firehose/preloader write can brick the device. Always image (read) before ever contemplating a write.
Chip-off is the last resort and irreversible in the sense that the board is disturbed and reballing is required to restore function.

Tools and materials required

Tier 1–4 (software):

USB-OTG adapter (USB-C or micro-USB to USB-A) and a basic USB mouse (+ USB keyboard/hub if needed).
PC (Windows/Linux/macOS) with scrcpy and the Android platform-tools (adb).
Correct, good-quality USB data cable (not charge-only).
Vendor USB drivers (Windows).

Tier 5 (chip-level):

Qualcomm: an EDL "deep-flash" cable (or test-point jig) and the correct signed Firehose loader (programmer) for that model. Tool: bkerler/edl or the newer edl-ng.
MediaTek: a normal USB cable, sometimes a test-point short. Tool: mtkclient (+ its libusb/driver setup, e.g. UsbDk/Zadig on Windows).
ISP: an ISP-capable programmer — UFI Box, EasyJTAG Plus, Medusa Pro, or an RIFF/ORT-class tool — with the matching eMMC/ISP adapter and jumper leads.
Micro-soldering: stereo microscope, hot-air and soldering station, fine 0.1 mm enamelled wire or ISP jumpers, flux, tweezers, regulated bench PSU with current display, ESD-safe mat and strap.
Boardview / schematic for the exact model (to locate test points — see below).

Prerequisites and safety

Confirm ownership / authorisation in writing before touching the device (#Legal and consent note).
Establish the device state first: Is the display alive? Was USB debugging ever enabled? Is it AFU or BFU right now? Is there a screen lock? Do you (or the owner) know the PIN/pattern/password? The passcode is often the whole ballgame on encrypted devices.
Keep the device charged and powered. If it is AFU, treat power loss as data loss (keys in RAM).
Work ESD-safe for any board work; use a bench PSU with current limiting for EDL/ISP so a short trips the limit instead of frying the chip.
Image before you write, always. Never flash, never "repair", until you have a verified read-only copy.
Have the target UI navigation memorised if you will drive the screen blind.

Step-by-step procedure

A. Tier 1 — OTG mouse (display works, touch dead)

Plug a USB-OTG adapter into the phone's charge port, then a USB mouse into the adapter.
Within a few seconds a pointer appears on the phone's own screen. Move it to unlock, open Settings, and navigate normally.
If you need to type (passwords), add a USB keyboard via an OTG hub, or use the on-screen keyboard with the mouse.
Once in, proceed to enable USB debugging (Tier 4) for reliable bulk extraction: Settings → About phone → tap Build number 7× → back → Developer options → USB debugging = ON.

If no pointer appears: the port may be charge-only/damaged, the adapter may be charge-only, or the phone may not support OTG host mode — move to Tier 2/3.

B. Tier 2 — scrcpy over ADB (USB debugging already enabled & authorised)

This is the best case: you see and control the whole phone on your PC.

Connect the phone by USB. Approve the RSA authorisation prompt if it appears (needs a working input method — OTG mouse — or a previously-authorised host).
Verify: adb devices should list the device as device (not unauthorized).
Launch mirroring: scrcpy — or, to blank the phone's own panel and save power: scrcpy --turn-screen-off --stay-awake
Control with your PC mouse/keyboard, unlock, and extract (Tier 4).

C. Tier 3 — scrcpy OTG mode (no debugging; blind HID control)

Use this when USB debugging was never enabled and you must turn it on with no touch. OTG mode makes the PC act as a USB keyboard/mouse to the phone via AOA HID; there is no screen mirror (scrcpy needs ADB for video, which you don't have yet).

Start OTG mode: scrcpy --otg (or scrcpy --otg -K -M to enable keyboard and mouse HID explicitly).
A blank scrcpy window with the logo appears — that is expected; it is only capturing your input.
Drive the phone blind. If the phone's display works you can watch the phone itself; if it is dark, use known geometry and keyboard Tab/Enter/arrow navigation. Goal: unlock → enable Developer options → enable USB debugging.
Once debugging is on, unplug, drop OTG, and switch to Tier 2 (scrcpy with mirror) for accurate control. Go slowly — a wrong blind tap into a reset/Repair-Mode flow can wipe the device (see #Risk to data).

D. Tier 4 — logical extraction once you have control

With an unlocked, debugging-authorised device:

Pull accessible user-visible storage: adb pull /sdcard/ ./recovered/ (photos, downloads, DCIM, WhatsApp media, etc.).
App data where allowed: adb backup -apk -shared -all -f backup.ab (deprecated on newer Android and increasingly blocked per-app; treat as best-effort).
Prefer the vendor's own backup / Smart Switch / local Google backup path through the mirrored UI when adb backup is unavailable.
This is the highest-yield method for a user recovering their own files, and it sidesteps the encryption problem entirely because the running, unlocked OS decrypts on the fly.

E. Tier 5 — chip-level imaging (SoC low-level modes)

Use only when the display and touch are both unusable and no debugging/backups exist. Read (image) only.

Qualcomm — EDL / Sahara / Firehose:

Enter EDL (9008): via an EDL/deep-flash cable, a test-point short to ground on boot, or adb reboot edl / fastboot oem edl if you still have that access. Test-point location varies by model — verify against the boardview/service schematic; do not guess.
Confirm enumeration as Qualcomm HS-USB QDLoader 9008.
Provide the correct signed Firehose programmer for that exact model (loaders are model/OEM-specific and signed; a wrong loader will not run).
Read partitions, e.g. with bkerler/edl: edl rl dump/ --genxml --skip=userdata to grab everything except userdata, or edl r userdata userdata.bin to image the user partition. (Adjust to your tool version, e.g. edl-ng.)

MediaTek — BROM / Preloader (mtkclient):

Power off. Hold Vol+ and Vol− (or the model's BROM combo / test-point short) while connecting USB to drop into BROM; release when detected.
Full read, skipping the huge encrypted userdata if you only want firmware/metadata: python mtk rl dump/ --skip=userdata
Or image a specific partition: python mtk r userdata userdata.bin
mtkclient uses the Kamakiri/BROM exploit path on supported SoCs; newer, patched SoCs may be unsupported.

ISP — in-system programming (eMMC):

Remove the shield. Under it, locate the eMMC ISP pads: CLK, CMD, DAT0, VCC (VCCQ), and GND. These pad positions are entirely model-specific — locate them from a verified test-point diagram/boardview for that exact board; never assume coordinates.
Wire those five lines to your ISP programmer (UFI/EasyJTAG/Medusa). Keep leads short; power the eMMC either from the programmer or the board, per your tool's guide — do not double-power.
Some eMMC devices need DAT0 pulled to GND at power-on to force boot-mode / prevent the CPU booting; follow the tool's model profile.
Read the full user area to a raw image (.bin). Verify the CID/eMMC size matches the known part.
UFS ISP is generally not practical (high-speed differential MPHY lanes, no friendly pads). For UFS, the SoC modes above, or professional chip-off with a UFS reader, are the realistic options.

Verifying the result

Software tiers: confirm file counts/sizes match expectations and that pulled media opens (thumbnails render, videos play). Checksum the copied tree.
Chip-level images: verify the dump size equals the reported flash/partition capacity; run file / a hex viewer / a partition parser. A valid GPT and mountable, plaintext partitions (e.g. the FAT/exfat portion, or an unencrypted FDE-off device) means real data.
The decisive check: can you actually mount and read plaintext user files from the userdata image? If the partition is FBE/FDE-encrypted and you have no keys, tools will show it as random/LUKS-like data — that is ciphertext, not a corrupt read. This is the difference between "I have the bytes" and "I have the data."
Hash every deliverable (SHA-256) and record it for the customer/chain-of-custody.

Success rate and limitations

Be brutally honest with the customer here.

Display-works/touch-dead: very high success (Tiers 1–2). You just needed an input path.
Display-dead but USB debugging was already on and authorised: high success via scrcpy mirror.
No debugging, encrypted, locked, and you don't have the passcode: low-to-zero for user data. Chip-level imaging will succeed at reading — but:
- FBE (Android 7+, near-universal): user files are encrypted with keys wrapped by the passcode and bound to hardware (TEE/Keymaster/StrongBox). BFU (post-reboot, never unlocked): user data is inaccessible, period. AFU (unlocked since boot, still powered): keys are in RAM — but you generally need a running-device forensic exploit to use them; a cold chip image after a reboot won't help.
- FDE (older devices): decryptable only with the passcode (and a brute force is throttled/hardware-bound on most).
- Hardware-bound keys mean you cannot move the chip to another board and decrypt — the keys never leave the original SoC's secure hardware.
What is NOT recoverable, realistically: encrypted user data on a locked modern device without the credential; anything after a factory reset (keys destroyed); anything on physically destroyed flash.
FRP is not data. Factory Reset Protection / activation locks are anti-theft features. Removing them does not recover data, and defeating them on a device you don't own is out of scope and unlawful. A legitimate data-recovery job needs the credential or an AFU live device — not an FRP bypass.
iOS: scrcpy/OTG-HID don't apply. SEP-bound, hardware-entangled encryption makes ISP/chip-off decryption infeasible on modern iPhones. The pragmatic recovery for a broken-screen iPhone you own is display/digitiser replacement plus the known passcode, then an encrypted iTunes/Finder or iCloud backup. See iPhone Screen Replacement for Data Recovery.

Common pitfalls and troubleshooting

"unauthorized" in adb devices: you still need to tap Allow on the RSA prompt — use an OTG mouse or a previously-trusted host. No input path = no authorisation.
Charge-only cable/adapter: silent failure. Swap to a known-good data cable and OTG adapter.
scrcpy shows nothing in OTG mode: that's by design (no video without ADB). Don't chase it as a bug.
Blindly triggering a wipe / Repair Mode: the classic irreversible mistake. Learn the exact menu before driving blind. When unsure, stop.
Rebooting an AFU device "to try again": can drop it to BFU and lose access to the keys. Don't reboot until extracted.
EDL enumerates but Firehose fails ("sahara" errors, hangs): wrong or unsigned loader for the model, or secure-boot rejecting it. You need the correct signed programmer.
MediaTek not entering BROM: wrong key combo/test point, patched BROM, or missing libusb driver (install UsbDk/Zadig).
ISP dump is all-FF or all-00, or wrong size: cold/badly-soldered joint, wrong pad, missing DAT0-to-GND boot short, or under-voltage. Reflow, re-verify pads against the boardview, check VCCQ.
You imaged userdata but it's "random": that's encryption, not corruption. Re-read #Success rate and limitations and reset expectations with the customer.
Cheapest fix overlooked: for many phones, simply replacing the screen/digitiser is faster, cheaper, and less risky than any of this — try that first when the board is otherwise healthy.

Legal and consent note

Only perform these procedures on a device you own or are explicitly, verifiably authorised to service. Get signed consent and proof of ownership before extraction, and keep a chain-of-custody and SHA-256 hashes of anything you deliver. Do not use any technique to circumvent screen-lock, activation-lock, or Factory Reset Protection on a device that is not yours — that is unlawful in most jurisdictions and outside the scope of legitimate repair/recovery. Data extraction for law-enforcement or third parties may require additional legal authority (warrant/consent). When in doubt, don't.

Sources

PhoneRepair.biz is a free community knowledge base. Data recovery and board-level repair carry a real risk of permanent data loss — when the data matters, back up any raw dump before modifying a device and consider a professional lab. Only work on devices you own or have documented authorization to service. See PhoneRepair:Legal notice.