Android & Samsung Data Recovery

A Galaxy that won't power on has almost always kept its data. The encrypted files sit intact in the storage package while a fault somewhere in the power or charging path stops the board from booting.

On Samsung's own Exynos-architecture boards with standard PMIC layouts, that job is split across Samsung's own silicon. The S2MPS and S2MPB families are the main PMIC, generating the core rails that feed the processor, RAM & storage. The S2MU and S2DOS families are the sub-PMIC: USB interfacing, charging control, and the AFC and Power Delivery negotiation that decides whether a charger does anything at all. A board pulling near zero current from a known-good charger, or refusing to enumerate on a PC, points at that second group first, and a dead charging path leaves the processor and the storage untouched.

Diagnosis is a multimeter in diode mode, not software. Nothing enumerates on a board that won't power: no ADB, no Download Mode, no Odin, so every decision comes from current draw at the port and diode-mode readings taken to ground. A rail reading at or near 0.000 V is a hard short; a healthy signal line reads a few hundred millivolts. Where the short sits decides the prognosis. A shorted charging path is a repair. A short on VDD_CORE implicates the processor itself, and on a file-based-encryption phone a destroyed processor means destroyed keys.

The Galaxy S24 Ultra has its own version of this, documented by the board-repair community rather than by any Samsung defect notice: a working phone, often on a charger or mid-video, goes totally unresponsive. It stays cold, draws zero or near-zero current from a good charger, and refuses Download Mode and recovery. The documented causes span the main PMIC, the USB-C sub-board and its charging IC, and shorted BGA joints under the processor or the storage package. No current-draw number on its own separates a failed charging IC from a shorted core rail, which is why we measure before we quote.

Samsung won't turn on data recovery carries the intake triage order, the per-rail prognosis table & the board states that end the conversation.

Honest first step: stop cycling it through chargers and don't let anyone flash it. There is no software step available on a board with no power, so every hour spent on one is an hour not spent measuring.

A boot loop is a symptom with several possible causes, and the single most destructive response is to flash firmware first and ask questions later. Odin writes; it never reads your data out. Under file-based encryption a wipe destroys key material, and nothing on the other side of a reflash brings it back.

The Galaxy S22 Ultra carries a boot-loop class the repair community has documented on both the Snapdragon & Exynos builds. Thermal stress fractures BGA joints under the processor, or inside the dual-layer interposer that joins the stacked board, and the phone loops at the boot splash or dies intermittently. The tell is temperature: a phone that boots cold and dies warm is describing expansion and contraction across a cracked joint, not corrupted firmware. Chilling the phone contracts the stack and can re-bridge that fracture long enough to boot for a few minutes.

That cold-boot window is a diagnostic clue and a chance to copy files right then. It is not a repair. Advice to put the phone in the freezer describes a real phenomenon and draws the wrong conclusion from it: chilling contracts the stack, warming re-opens the fracture, and the crack is still sitting there either way. The lasting path is mechanical, meaning separating the board stack and reballing the processor & RAM, or, when the board is past that, moving the paired set to a donor board.

On the legacy fleet the same symptom means something else. When an older Galaxy of the S5, Note 4, and Note Edge class reports a memory read failure in Download Mode, the eMMC controller has stopped answering the processor. That is hardware, not a corrupted partition table, and flashing a PIT file or firmware into it at that point risks finishing off what is left.

Samsung Galaxy boot loop recovery sorts the loop patterns by fault class & spells out what each Odin CSC choice does to userdata.

Honest first step: if the phone still reaches the home screen at all, even for thirty seconds, copy your photos off in that window before you try anything else.

Liquid damage is a chemical process, not a drying problem. That one sentence decides what you should do in the next ten minutes.

Water sitting on a powered board acts as an electrolyte bridging points held at different voltages, which forms a microscopic galvanic cell. Metal at the anode dissolves into solution, the ions migrate, and they plate back out at the cathode as conductive dendrites. Traces and pads are physically consumed while new shorts grow in places that were never connected. The reaction concentrates under the BGA packages, where the liquid wicks in and cannot evaporate.

Unpowered oxidation is slow. Applying power drives continuous current through that electrolyte and accelerates the dissolution, which is how a board that could have been cleaned becomes a board that cannot. Rice does nothing about any of it, because the damage is corrosion underneath the chips rather than moisture in an air gap.

Honest first step: stop charging it and stop turning it on to check. Every power cycle is chemistry, not diagnostics. On the bench the phone comes apart, the shields come off, the board is cleaned ultrasonically to halt the reaction, and only then do we go looking for the shorts with a current-limited supply and a thermal camera.

A board broken in half is the one presentation where the original board may genuinely not come back, and it is where the paired-set transplant belongs. Small breaks are different: a severed trace is reconstructed with micro-jumper wire under the microscope, and the phone boots on its own board afterward.

When the board is past that, the storage chip still never moves alone. The keys that unlock your files live in the processor's secure hardware, so a viable transplant moves the processor with its stacked RAM, the storage, and, on Galaxy S21 and newer flagships, the discrete Knox Vault secure element the bench calls the EEPROM or Pin Code IC, all as one set onto a donor board matched by model number & processor variant. Leave that last part behind and the phone boots, then rejects the correct PIN. Samsung's heavy underfill turns the removal alone into a long job before any reballing starts.

That work is bench hours, not a surcharge. It quotes from the same $500–$750 range as a charging-circuit repair.

Often yes, and on many models without opening the phone at all. What does not exist is a USB shortcut for anyone who doesn't have your screen lock.

ADB is not that shortcut. USB debugging has to have been switched on before the screen broke, and even then the phone refuses an unfamiliar computer until someone approves that computer's key in an on-screen dialog, on an unlocked device. MTP sits behind the lock as well. A shop promising to pull files over a cable from a locked black-screen phone is describing something the phone will not do.

The owner, though, is not locked out. On Galaxy models that support DisplayPort Alt Mode over USB-C, a USB-C hub with HDMI out plus a plain USB keyboard puts the phone on a monitor and lets you blind-enter your own PIN. That satisfies Gatekeeper & Weaver, moves the phone into its unlocked state, and brings up Samsung DeX or mirroring, at which point Smart Switch or MTP copies the files off. That path enters your credential. It never works around it.

Three things shut it down. Auto Blocker, which was opt-in in One UI 6.0 and ships enabled by default on devices launching with One UI 6.1.1, blocks commands sent over the cable. The separate setting that blocks USB connections while the phone is locked does the same. And Maintenance Mode, if you turned it on before handing the phone over, boots an empty profile and keeps your real data sealed until you exit it on a working display. Where any of those apply, the answer is a temporary donor screen or a board repair so you can unlock the phone the normal way. The Fold & Flip lines split sharply here, and that matrix is in the generation section below.

A broken fingerprint or face-unlock sensor changes none of this. Biometrics gate the screen-lock credential and never replace it in the key derivation, and a phone that has not been unlocked since it powered on disables biometric unlock outright and accepts only the PIN, pattern, or password. The sensor being dead is irrelevant to whether the data comes back.

We need your screen lock, and there is no version of this job where we get around it. That is not a policy we chose. It is how the key derivation works.

File-based encryption arrived in Android 7.0 and is mandatory for devices launching with Android 10 and later. Your files live in Credential Encrypted storage, which unlocks only after the phone boots and you enter the credential. Deriving those keys needs both your credential and hardware-held secrets the secure environment releases, so the credential alone off the device is useless, and so is the hardware without it.

Guessing is not an option either, and not because we lack patience. Gatekeeper verifies the PIN, pattern, or password inside the secure environment and refuses service during an escalating timeout after failed attempts, with the failure count held in anti-replay storage so a reboot doesn't clear it. A Weaver slot holds a high-entropy secret released only on an exact match, and enforces an absolute attempt ceiling, after which the slot is wiped and the data is permanently unrecoverable. On Exynos & Qualcomm silicon that secret never leaves the secure hardware, so the check cannot be moved onto a rack of GPUs.

Where those keys physically sit changes by generation and tier, and the answer to you does not change with it. Older flagships kept custody in a TrustZone Keymaster keystore. Galaxy S21 and later flagships moved it into Knox Vault, which now reaches newer A-series models such as the A55 but not budget boards like the A05 and A06, and MediaTek-based budget Galaxies run third-party trusted environments such as Kinibi with no Knox Vault at all. In every one of those cases we repair the hardware and you unlock the phone.

Those programs operate at the file level over MTP or ADB, which means they list what still exists on a phone you can already unlock. That is the whole capability, and it is a real one on a working phone. It is not what the ads describe.

MTP & ADB are file-level interfaces mediated by system services; neither exposes the block device. Reaching blocks needs an unlocked bootloader or root, both require an unlocked and authorized session first, and on devices shipping with One UI 6.1.1 and later Auto Blocker is on by default and blocks commands over the cable to a locked phone.

The deeper problem is that there is nothing to read. Under file-based encryption the credential-encrypted file keys are derived when you unlock the phone and held in kernel memory from that point, so a phone that has not been unlocked since it booted has no usable key material to offer. A PC on the other end of the cable is talking to a device that has nothing decrypted to show it.

So why does the demo scan always find something? Because it enumerates live objects and cached thumbnails on a working, unlocked phone. Those files were never deleted. Showing you a grid of thumbnails it never had to decrypt anything to reach, then asking for payment to "recover" them, is the trick, and it is why the scan looks so convincing before the purchase and so empty after it.

Permanently deleted files on modern internal storage are a harder no than most pages admit. Deletion destroys that file's key, so the blocks become unreadable ciphertext immediately, and F2FS discard plus scheduled fstrim then clear the physical blocks underneath. No scan reverses either half of that. A factory reset does the same thing to everything at once by destroying the key material wholesale, which is why post-reset recovery does not exist on these phones.

Start with the places that hold files which were never actually deleted, because those are the only ones a deletion did not destroy the key for.

On the handset, Samsung Gallery Trash keeps deleted photos for roughly 30 days, and the unified My Files trash in One UI 6 and later also holds recently deleted Gallery and Voice Recorder items. Both live in credential-encrypted storage, so they need a working, unlocked phone to reach. Off the handset is where the odds improve if the phone is dead: Google Photos & OneDrive trash, older Samsung Cloud backups made without end-to-end encryption, an existing Smart Switch backup on a PC, and whatever other cloud accounts were syncing. Those copies do not depend on your phone booting. One caveat there gets skipped constantly: Samsung Cloud backups made under Knox Matrix Enhanced Data Protection, available from One UI 6.1, are end-to-end encrypted, and without your recovery code nobody restores them, us included.

An SD card is a genuinely different animal. Formatted as portable storage it carries an ordinary unencrypted FAT or exFAT filesystem that classic carving tools understand, so deleted files on a card often do come back. That result says nothing about your internal storage, which is encrypted and actively trimmed, and anyone using the card result to imply the phone will behave the same way is selling you the wrong conclusion. Samsung disables encrypted adoptable storage natively, and current Galaxy S and Z flagships have no card slot at all.

Odin pushes Samsung-signed firmware into partitions and has no documented command path that reads user data back out, which makes flashing a data-risk decision taken last rather than a triage step taken first.

The CSC file decides the consequence. Standard CSC and repair firmware wipe userdata, and on 2025-and-later flagships the A/B partition structure has made even the HOME_CSC route that traditionally preserved it a soft-brick risk, so any Odin flash now carries a real chance of forcing a full wipe. Qualcomm's emergency download mode is no better an answer, whatever the boxes advertise: it offers no path past your screen lock, and on a file-based-encryption phone a raw read through it returns ciphertext, because the credential-derived keys never materialize in that session at all.

Secure Folder is not a folder. It is an isolated Knox container running as a separate Android user profile with its own file-based encryption keys, so it does not open when your main profile opens.

Three consequences follow, and a lab should say all three before taking your money. Standard Smart Switch backups to a PC or SD card do not contain Secure Folder data, and Samsung discontinued cloud backup for it, so an existing backup almost certainly does not have it. Recovering it needs a fully booting phone, your separate Secure Folder credential, and a device-to-device transfer performed while the container is unlocked. And if the Knox fuse was tripped by someone trying to flash a boot loop away, the keys protecting that container are withheld permanently, even after the phone is repaired & boots normally.

No chip-off, raw dump, cloud pull, or rooted phone produces Secure Folder contents. Any offer that says otherwise is describing something that does not happen.

A phone showing a null IMEI or no cellular service has a damaged identity partition, not damaged files. It scares customers and inexperienced technicians into the wrong conclusion often enough to be worth its own paragraph.

The EFS partition holds device identity and radio calibration: IMEI, MAC addresses & RF tuning data. It sits apart from the userdata partition your photos and messages live in, and the kernel mounts them independently. A phone with a destroyed EFS still boots, still decrypts when you enter your credential, and still hands over every file over a cable or over Wi-Fi. Your eSIM profile is separate again, living in its own secure element rather than in either partition, so it has no bearing on whether your data comes back. Recovering the data and restoring the phone's cellular identity are two different jobs with two different outcomes.