Chromebook Data Recovery

Partition Layout

ChromeOS formats the eMMC using a GUID Partition Table (GPT) with up to 12 partitions. The layout includes two kernel partitions (KERNEL-A and KERNEL-B), two read-only root filesystems (ROOT-A and ROOT-B), and one writable stateful partition (STATE). User data lives exclusively on the STATE partition, which is formatted as ext4. The dual-kernel and dual-root design allows ChromeOS to apply updates to the inactive set and swap on reboot; this is irrelevant to data recovery because user files are never stored on kernel or root partitions.

Encryption: dm-crypt, fscrypt, and Hardware Key Binding

ChromeOS protects user data through the cryptohome system. Older Chromebooks (pre-2018) used ecryptfs to encrypt individual files. Modern Chromebooks use ext4-native encryption (fscrypt) combined with dm-crypt for full-partition encryption of the stateful partition.

The encryption key is derived from two inputs: the user's Google account password and a high-entropy hardware secret stored in the TPM (Trusted Platform Module) or Google's custom Titan C / Cr50 security chip. The hardware secret cannot be extracted from the TPM; it can only be used by the TPM on the original board. This means a raw dump of the eMMC chip, taken via chip-off without the original board's TPM, produces encrypted data that cannot be decrypted without brute-forcing the hardware key component.

For data recovery, this means the most reliable path is repairing the original logic board so that the TPM can participate in key derivation. If the board is repairable, we boot ChromeOS far enough for cryptohome to mount the user's vault, then transfer files off the device. If board repair is not possible but ISP imaging succeeds, we can attempt offline decryption with the user's password, but this only works on older devices that usedecryptfs without hardware key binding.

ISP Recovery on Chromebook Boards

ISP (In-System Programming) connects directly to the eMMC chip's signal lines through test points on the Chromebook's PCB. We locate the CLK (clock), CMD (command), DAT0 through DAT7 (8-bit data bus), VCC (3.3V core power), VCCQ (1.8V or 3.3V I/O power), and GND pads using board schematics or by tracing signals from the eMMC BGA footprint.

An ISP adapter provides regulated power directly to the eMMC chip, bypassing the dead host board's power circuitry. The adapter sends standard MMC read commands to the eMMC controller. If the controller responds, we image the chip sector by sector using PC-3000 Flash. The resulting image contains the full GPT layout, including the encrypted stateful partition.

ISP is the preferred method because it avoids the thermal stress of desoldering and preserves the chip for reinstallation. On Chromebooks where the eMMC controller is healthy but the host SoC or PMIC is dead, ISP produces a complete image of a typical 64 GB eMMC. Transfer speed depends on the bus width available at the test points; 1-bit DAT0 reads are slower but reliable over flying wires, while chip-off with a shielded BGA socket enables full 8-bit bus speeds.

Chip-Off BGA Recovery

When ISP fails because the eMMC controller is locked or the test points are damaged, we desolder the BGA eMMC package. The board is preheated to 150°C to reduce thermal gradient stress, then a focused hot-air nozzle at 260-280°C melts the solder balls. The chip is lifted, cleaned, and placed in a BGA-to-socket adapter matched to the 153-ball or 169-ball pinout.

PC-3000 Flash communicates with the eMMC controller through the socket adapter. If the controller responds, imaging proceeds normally. If the controller is dead, raw NAND reading bypasses the controller entirely. Raw reading requires identifying the eMMC manufacturer (Samsung, Toshiba/Kioxia, SK Hynix, or Micron) and applying the correct ECC algorithm (BCH or LDPC) and XOR descrambling pattern to reconstruct the logical data from physical NAND pages.

eMMC vs. NVMe in Newer Chromebooks

Premium Chromebooks (Google Pixelbook Go, HP Elite Dragonfly Chromebook, Framework Chromebook) use NVMe SSDs instead of eMMC. NVMe Chromebooks follow the same ChromeOS encryption model (TPM + user password), but the storage interface and recovery tooling differ. NVMe drives use PCIe lanes and the NVMe command set rather than the MMC protocol. Recovery of NVMe Chromebooks uses our SSD recovery process with PC-3000 SSD or PC-3000 Portable III. If the NVMe drive is removable (M.2 2242 or 2280), it can be read in another machine; however, the encrypted data still requires the original board's TPM for decryption.

One additional consideration for NVMe Chromebooks: if files were deleted (emptied from Trash) before the device failed, the NVMe controller executes TRIM commands that zero out the underlying flash blocks. Deleted files on an NVMe Chromebook are not recoverable through any method.

Common eMMC Chips in Chromebooks

Chromebook OEMs source eMMC from four primary manufacturers. PC-3000 Flash includes recovery profiles for each controller family:

• Samsung (KLMAG, KLMBG series): Found in Samsung Chromebooks and many HP models. Samsung eMMC controllers use LDPC ECC and respond reliably to MMC commands via ISP.
• Toshiba/Kioxia (THGBMHG, THGBMDG series): Common in Acer Chromebooks and budget HP models. Firmware lockouts on Toshiba eMMC can sometimes be resolved through vendor-specific MMC commands during ISP sessions.
• SK Hynix (H26M, H26T series): Used in Lenovo Chromebooks and Dell education models. Known for FTL inconsistency after power loss during garbage collection, causing boot loops. ISP with vendor commands can force the controller to rebuild its tables.
• Micron (MTFC series): Found in ASUS Chromebooks and some Dell models. Micron eMMC uses a controller with similarities to their SSD line. PC-3000 Flash handles chip-off recovery with Micron-specific ECC profiles.