Most partitions on a phone can be reflashed from a stock firmware package without consequence — boot, system, and vendor are generic images shared by every unit of that model. The efs partition is different. It stores data that's unique to your individual device: the IMEI (or IMEIs, on dual-SIM phones), the Wi-Fi and Bluetooth MAC addresses, and modem calibration values written at the factory. Wipe or corrupt it and there's no generic image to restore from, because the values only ever existed on that one unit.
The efs partition is small, usually a few dozen megabytes, but it's dense. It typically contains the NV (non-volatile) items the baseband processor reads on boot: IMEI, product code, and on some Qualcomm platforms the modem's calibration and RF tuning data. The persist partition, which sits alongside it, commonly holds sensor calibration (accelerometer, gyroscope offsets), fingerprint sensor calibration on some models, and on Samsung devices the DRM keys used for Widevine content protection. Neither partition is part of the firmware package you download for a given model — both are written once during factory calibration and never touched by a normal OTA update.
This is why an IMEI going to 0 or Unknown after a botched flash is a specific, well-known failure mode rather than a generic bug: something wrote zeros or garbage over efs, and the modem has nothing left to read.
Stock OTA updates never touch efs or persist, and a normal boot image patch for root doesn't either, since boot.img has nothing to do with modem NV storage. The risk is concentrated in full-image flashes and repartitioning operations.
This requires root, since these partitions sit outside what the package manager or a stock ROM will let you read directly. With a root shell available, the raw block devices are usually reachable under /dev/block/bootdevice/by-name/ or /dev/block/platform/.../by-name/ depending on the SoC vendor. Confirm the exact partition name first:
adb shell su -c "ls -la /dev/block/bootdevice/by-name/ | grep -Ei 'efs|persist'"Once you have the correct path, dump each partition to an image file on internal storage, then pull it to your computer:
adb shell su -c "dd if=/dev/block/bootdevice/by-name/efs of=/sdcard/efs_backup.img"
adb shell su -c "dd if=/dev/block/bootdevice/by-name/persist of=/sdcard/persist_backup.img"
adb pull /sdcard/efs_backup.img
adb pull /sdcard/persist_backup.imgMove both files somewhere off the phone entirely — a backup that lives only on the device you're about to flash doesn't help if that flash goes wrong. Keep a copy per device, since these images are meaningless on any other unit; they contain data specific to the phone they were pulled from.
Restoring is the same command in reverse, writing the image back to the block device rather than reading from it:
adb push efs_backup.img /sdcard/
adb shell su -c "dd if=/sdcard/efs_backup.img of=/dev/block/bootdevice/by-name/efs"Reboot after restoring and confirm the IMEI is back with adb shell service call iphonesubinfo 1 (output is encoded and takes some deciphering) or more simply by checking Settings > About Phone > IMEI, or dialing *#06#. If the IMEI still reads zero after a correct restore, the modem partition itself (not efs) may also need attention, which is a different and more OEM-specific repair path.
Some OEM service tools (Qualcomm QPST/QFIL-based, or brand-specific engineering software) can rewrite NV items if you have the original IMEI recorded from the box label, a prior invoice, or the sticker under the battery on removable-battery devices. This isn't something ADB or fastboot can do on their own — it requires vendor-specific tooling and, on many carrier-locked devices, is explicitly restricted. Recovering a lost IMEI without a backup is the harder and less reliable path, which is the whole reason to take the backup before flashing rather than after something breaks.