Mobile Device Recovery State and Board-Level Preservation
On an encrypted phone, the original board, its security hardware and the device's current lock state can matter as much as the storage chip itself. The safer path is usually the smallest authorized step that produces a verified export — but never at the cost of charging or powering a device that is wet, overheated or has a damaged battery.
- On an encrypted phone, the original board, its security hardware and the current lock state can matter as much as the storage chip.
- "After first unlock" does not mean every file is readable: availability depends on protection class or storage type, lock state and user profile.
- Liquid, heat or battery damage comes first: do not charge or keep a hazardous device powered just to preserve its unlock state.
- Board repair for data aims at one authorized export; it is separate from swapping the board or making the phone usable again.
- A completed backup or export can still miss app data, so check what it actually contains before relying on it.
What "BFU" and "AFU" do and do not mean
"Before First Unlock" (BFU) and "After First Unlock" (AFU) are simplified forensic labels, not a switch between "everything encrypted" and "everything decrypted." They are useful shorthand for one fact: a phone that has booted but has not yet been unlocked, and the same phone after the user has authenticated once since boot, expose different sets of keys. What is actually reachable at a given moment depends on more than that one label.
On Apple devices, availability depends on each file's Data Protection class and on the current lock state. Apple documents that for Class A (Complete Protection) the decrypted class key is discarded when the device locks, so that data is inaccessible until the user unlocks again, while for Class C (Protected Until First User Authentication) the class key is not removed from memory when the device locks — and Class C is the default for third-party app data not otherwise assigned. "Unlocked right now" and "unlocked once since boot, currently locked" are therefore different states, and an AFU device can still have files it cannot read while locked. The full class model, keybags and restart behavior are covered in iPhone Data Protection and Secure Enclave Recovery.
On Android devices that use file-based encryption, the comparable distinction is between Device Encrypted (DE) storage, available during Direct Boot before the user unlocks, and Credential Encrypted (CE) storage, the default storage location, available only after the user unlocks. AOSP also documents that each user, and each work profile, gets its own DE and CE keys, so unlocking one user does not necessarily make another user's or profile's CE storage available. Apple's class names are not a complete description of Android, and implementations vary by Android version and manufacturer; the CE/DE and Keystore layers are covered in Android FBE, Keystore and Hardware-Bound Recovery.
Recording the state the device is actually in
The table below is a way to record the observed state and what each state puts at risk. It is not a sequence to move a device through, and it does not replace qualified handling of a damaged device.
Scroll horizontally to see the full table →
| Observed state | What to record | Dependency or state at risk | Next authorized branch | Limit |
|---|---|---|---|---|
| Dry, physically stable, currently unlocked | What is on screen if visible, whether it stays unlocked, connected computer or accessories | The unlocked session itself; auto-lock or a restart ends it | Authorized export or backup through the owner's normal platform path, after checking what existing backups already cover | An unlocked session does not guarantee that every app's data reaches the export |
| Dry, stable, locked after a first unlock since boot | Whether it has restarted since the incident, signs of activity such as notifications or vibration | Keys held in memory since first unlock; a restart, update or reset can remove them | Avoid restarts and settings changes; plan export with the owner's credential and any previously trusted computer | Some data stays unavailable while locked, depending on class or storage type |
| Rebooted, not yet unlocked | When and why it restarted, as far as known | Credential-dependent storage stays locked until the user authenticates | Recovery depends on the owner's valid credential and the platform's own unlock path | Raw storage access does not replace the credential or the original security hardware |
| Powered off and damaged (dry) | Physical damage, last known state, any repair history | The original board, security components and storage together | Assessment of whether targeted repair can restore power and communication for an export | Whether it reaches a usable state is not known until assessment; nothing here promises it will |
| Liquid, heat, swelling or battery hazard | Liquid type and exposure if known, whether it was charged or powered since, visible swelling, heat or smell | Further electrical, electrochemical or thermal damage, and personal safety | Stop charging and testing; qualified handling decides how to make the device safe before anything else | Any unlock state may be lost; that is accepted in exchange for not adding damage or risk |
If the state is unknown — a black screen with no sign of activity, for example — record it as unknown. Do not test it with a forced restart, a reset or a recovery mode, because each of those can change the very state that is being described.
Physical hazard outranks unlock state
Preserving an unlock state never justifies charging, heating or keeping powered a device that is wet, overheated or has a swollen or damaged battery. Physical and electrical hazards, and the risk of further damage, come first; the decision whether a hazardous device should stay powered or be shut down belongs to qualified handling based on its actual condition, not to a universal "keep it on" or "switch it off" rule.
A wet or previously wet phone should not be dried with heat, charged, or powered on just to test it, for the same reasons a wet hard drive shouldn't be (see water, fire and contaminated-drive recovery): corrosion and residue can keep developing after the device looks dry, and applying power accelerates exactly that process. Apple's liquid-detection support article, for example, warns that a wet connector or cable can corrode and fail if charged, and advises against external heat sources, compressed air, foreign objects in the connector and bags of rice. That guidance concerns liquid in the Lightning or USB-C connector or accessory; it is not a laboratory protocol for a submerged phone, and its everyday exceptions should not be read as covering board-level liquid damage.
Peripheral failure is not board failure
A broken display, damaged touch digitizer, dead charging port, failed battery or cracked housing can leave the SoC, storage and key hierarchy intact underneath. A repair-for-data workflow in that situation may only need to restore power, display or control, or USB communication long enough to perform an authorized backup or export — not fix the phone for continued daily use.
A dry device with a broken screen does not become accessible just because it is connected by USB. Whether a computer can back it up depends on the platform: the device may need to be unlocked, a computer that has not been trusted or paired before may need confirmation on the device itself, the USB mode may need to be selected on the device, and the backup method has to be supported for that platform and data. A previously trusted computer can change what is possible; a new one often cannot do much without working screen input.
Why the original board usually matters
An intact storage chip is not the same as readable user data. On modern phones, the keys that protect user data are tied to security hardware on the original board and, for credential-protected data, to the user's credential. Apple states that a UID fused into the SoC at manufacturing allows data to be cryptographically tied to a particular device. AOSP's file-based encryption documentation describes FBE keys stored encrypted on disk under Keystore keys that are not exposed outside the Trusted Execution Environment, with Verified Boot ensuring the keys cannot be unlocked unless a trusted operating system has booted, and CE keys that additionally require the user's lock-screen credential.
That is why chip-off cannot be treated as a general fallback for modern encrypted phones: moving the storage to another board, or pairing it with a replacement board, does not bring the original key hierarchy with it. Ordinary consumer repair aims to make the phone work again and may replace the logic board or the whole device; for data recovery, that can produce a working phone while the original encrypted data on the discarded board becomes unreachable. Preserving the original board is often more important than restoring the device with replacement electronics.
This does not mean that no repair is possible unless every original component is kept. Peripheral parts such as displays, batteries or ports are frequently what fails, and replacing them is a normal part of repair-for-data. The point is narrower: components that hold or enforce the device's key material, and the storage paired with them, should not be swapped away before the data is out.
Board repair and data export are separate steps
Board-level work aimed at restoring power, a display path or USB communication is a recovery step when it is done specifically to enable an authorized export, rather than to return the device to retail condition. Framed that way, it belongs in the same category as HDD PCB repair: temporary, targeted and oriented toward acquisition rather than long-term serviceability. Once an export exists, further recovery work happens against the exported data rather than on the original hardware.
Two things are easy to confuse here. Repairing the original board, so that the original device can unlock with the owner's credential and produce an export, keeps the data's key dependencies. Swapping in a different, working board produces a working phone, not the original data. A repaired device is also not yet a recovery result: the result is the export, and its contents still have to be checked. This page does not describe repair procedures, and it does not cover bypassing authentication — recovery here assumes the owner's valid credential and the platform's own unlock path.
Avoid unnecessary updates, resets and power cycles
An accessible but damaged device that is still running, and is not a physical hazard, should not be power-cycled, updated or reset out of habit while a data-preserving plan is worked out — each of those actions can change the cryptographic or application state before anything has been copied off. The same applies to changing settings to "see what happens." This is the same caution that applies to not power-cycling a failing HDD or not mounting a damaged filesystem read-write. A factory reset in particular should be treated as a cryptographic destruction event, not a reversible step. None of this overrides the previous section: for a wet, hot or swollen device, hazard handling decides.
What to inventory before any invasive work
Before physically invasive work on an unstable device, establish what is already known and what already exists elsewhere. That can make the invasive step unnecessary, or narrow it to what is actually missing.
- Model and operating system version, if known.
- The observed screen and power state, recorded without changing settings to find out more.
- Whether the owner has the credentials the device needs, and whether a previously paired or trusted computer exists.
- Cloud accounts and computer backups: the date of the most recent one, and what it covers.
- Other synchronized devices that may hold the same data.
- Peripheral damage, liquid or heat exposure, and any earlier repair attempts.
Credentials are part of the owner's own process and should be handled directly with whoever is authorized to perform the work. Do not enter passwords, passcodes or recovery keys into public web forms, chats or shared documents.
What an export or backup does and does not prove
"Backup completed" means the backup process finished; it does not prove that every needed app record, photo or file is in it. Some app data may not be included in a given backup type, some apps keep their own data outside the platform backup, and some content can depend on an app's own account or keys. Whether a local backup was encrypted, and with which password, can affect what it contains on some platforms and whether it can be opened later. Cloud sync is also not the same as an independent historical backup: a synchronized copy can reflect the current, possibly damaged state, and deletions can propagate.
A useful export record states which app data, photos and files were included, what was not available, whether the backup is encrypted and how its password is held, and how the copy can be checked. Opening the specific items that matter, rather than trusting a summary, is the practical check; How to Validate Recovered Data covers what different checks can and cannot show.
The question for a damaged phone isn't just "can this be repaired?" It's "what is the minimum, safe and authorized step that produces a verified export, without changing the cryptographic or application state along the way?"
Training scenarios
Training scenario: a dry phone with a broken display that was unlocked before the drop
After a drop, the display shows nothing usable, but the phone still vibrates for notifications. It had been unlocked since its last restart and has not restarted since. There is no liquid exposure, the device is not hot, and an older computer backup exists.
This looks like a peripheral failure with the board still working, and the device may still hold keys from its first unlock. That does not make it accessible over USB: whether a computer can back it up depends on whether it is currently locked, whether that computer was trusted before, and what the platform's backup supports.
Avoid restarting, updating or resetting it. Check what the existing backup and cloud accounts already cover. If a previously trusted computer can make an authorized backup without changes on the device, that is one option; otherwise, a targeted display or connector repair for data that keeps the original board, followed by an export.
The current state can still be lost, for example through an automatic lock or restart. A finished backup may omit some app data, so the items that matter need to be checked in the result.
Training scenario: a liquid-damaged phone that still works
The phone was in water, looks dry, and the screen and touch still work. The battery is low, and the owner wants to charge it and keep it on so it does not lose its unlocked state.
A phone that works now is not necessarily safe: residue and corrosion can keep developing, and applying power can add electrical and electrochemical damage. Preserving the unlock state is not a reason to charge it or keep it powered. A connector liquid alert, if one appears, describes the connector, not the board.
Do not charge it, heat-dry it or attempt a live acquisition. If there is any heat, swelling, smoke or unusual smell, treat it as a battery hazard and keep away from it. Otherwise, hand it to qualified handling, which decides whether it should stay powered or be shut down based on its condition. Meanwhile, check from another device what cloud accounts and backups already hold.
The unlocked state may be lost; that cost is accepted to avoid adding damage or risk. Nothing at this stage guarantees that the device can later produce an export.
Technical references: Apple Platform Security: Data Protection classes — Class A key discarded on lock; Class C key kept in memory after first unlock · Apple Platform Security: The Secure Enclave — UID fused into the SoC ties data to a device · AOSP: File-based encryption — Direct Boot, per-user and per-profile DE/CE keys, TEE-backed key storage and Verified Boot · Apple Support: liquid-detection alert on iPhone — charging and drying cautions for a wet connector. The Apple pages describe Apple platforms only, and the liquid-detection article is consumer guidance for the connector, not a lab protocol. AOSP describes FBE as supported from Android 7.0 and required for devices launching with Android 10 and higher; manufacturer implementations vary.
Related: iPhone Data Protection and Secure Enclave Recovery · Android FBE, Keystore and Hardware-Bound Recovery · Water, Fire and Contaminated-Drive Recovery · How to Validate Recovered Data · Mobile Device and Cloud Recovery Tools · Phone or Tablet Data Loss