WD My Cloud Data Recovery

How the Bridge Chip Encrypts Data Transparently

The USB-to-SATA bridge chip sits between the host controller and the physical hard drive. It generates a Data Encryption Key (DEK), typically stored redundantly in both the bridge board EEPROM and hidden sectors on the drive itself.

Every block written to the drive passes through the chip's AES-256 cipher. The user never sees the encryption because the bridge decrypts automatically on read. When the bridge fails, the drive looks unreadable rather than encrypted, which leads users to attempt destructive recovery steps.

JMicron JMS561

It's in WD external USB drives, and it does hardware AES. The wrapped key is held in more than one place, so a destroyed bridge board does not by itself take the decryption path with it. Not present in WD My Cloud NAS units.

JMicron JMS538S

Single-drive bridge used in WD My Book and My Passport USB external drives. Applies AES-256 transparently even with no user password. Shucking the drive yields ciphertext on every sector. Not present in WD My Cloud NAS units.

Symwave SW6316

Alternative bridge chip found in some WD enclosure generations. Same AES-256 behavior: encryption is on by default and direct SATA attachment produces ciphertext. On these designs the wrapped key is held in the drive's Service Area as well as the bridge EEPROM, which is where we read it from.

Recovery Path for Bridge-Encrypted Drives

For WD My Book and similar USB external drives with bridge-chip encryption, we address decryption at the board level. The first step is imaging the drive through a write-blocker to preserve the current sector state.

If the original bridge PCB is intact but the enclosure logic has failed, we repair the PCB using microsoldering equipment (Hakko FM-2032 on FM-203 or FX-951 base, Atten 862 hot air rework station) to restore the bridge chip's power and data paths.

If the PCB can't be repaired, it comes down to the key material. When nobody ever set a password, the key-encryption key is derived from a factory default.

We recover the key itself, either from the original bridge EEPROM or from the backup copy in Service Area modules on the drive. Then we decrypt the drive image with it. Possession of the correct key determines a readable result, not board parity.

3.3 V power-pin warning: WD drives pulled out of enclosures can use the SATA 3.3 V power disable (PWDIS) feature on Pin 3. If your power supply puts 3.3 V on that pin, the drive won't spin up.

Software Volume Encryption, Not the Bridge Chip

This is the software volume encryption on multi-bay My Cloud units, the kind you turn on per volume in the dashboard. It sits on top of the mdadm RAID & EXT4. It isn't the hardware bridge-chip encryption found on WD My Book & My Passport USB drives.

Keep the two separate. Bridge-chip encryption is bound to a JMicron or Symwave chip on an external USB enclosure board, covered in the bridge-encryption section above. The failure to mount is purely the NAS OS forgetting how to mount a volume it can still read once you re-supply the passphrase.

This Is Not the CVE-2025-30247 Advisory

A volume that stops mounting after an update is a configuration problem, not a security flaw. It is separate from the CVE-2025-30247 advisory, which we cover on its own page. If you came here because of that advisory rather than a missing share, that dedicated page is the right place to read about it.

mdadm Superblock Fields That Define the Array

Reading the superblock read-only from each clone with mdadm --examine returns the parameters an assembly needs. Nothing in that list is held by the enclosure.

Where that superblock sits depends on the metadata version, which is why locating it is the first step rather than an assumption. Versions 0.90 and 1.0 are stored at the end of the device with the data payload at offset 0. Version 1.1 sits at the absolute start. The modern default, 1.2, sits 4 KiB from the start with the payload at a calculated offset.

Chassis Swap Rewrites the Array Metadata

The advice that circulates on support forums is to buy a working enclosure of the same model and move the drives across. That works when the only thing that failed was the chassis power supply. It goes badly when the original crash was logical, because the next step a NAS dashboard offers for an unfamiliar set of drives is a write.

If a dashboard step re-creates the array, it writes new md superblocks over the old ones. mdadm's documentation says a re-created array can get a different data offset, so the boundary the EXT4 filesystem was measured from can move. The original description of the array isn't on the disks anymore for anyone to read. An enclosure failure that would have been a straight imaging job becomes a hunt for filesystem structures with no map to check them against.

On our side the equivalent destructive Linux operation is mdadm --create, and it never runs against original media here. Assembly happens on clones, read-only, after the superblocks have been read and recorded. If the geometry has to be derived because the metadata is already gone, that derivation runs against images too.

Dead Board Cases and Failing Member Cases Diverge at Intake

Both start the same way, with a write-blocked sector image of every member, and only one of them ends there. A dead main board leaves healthy disks whose only problem is that nothing is assembling them, so imaging is a clean sequential pass on a PC-3000 Portable III, PC-3000 Express, or DeepSpar Disk Imager, and the work that matters happens afterward at the md layer.

A failing member is a media problem and gets handled as one. Read timeouts, retry limits, and pass ordering are set per drive before the imaging starts, weak areas are deferred rather than hammered, and array assembly waits until the image is complete enough to trust. Assembling first and imaging later is how a marginal drive turns into a mechanical case mid-job. Where superblock metadata was destroyed before the drives reached us, the geometry gets derived from the member images in Data Extractor Express RAID Edition instead of read from disk.

A third intake case is not a failure at all. Western Digital ended support for the pre-OS 5 My Cloud generations on April 15, 2022, which removed remote access and mobile app connectivity for those units. A My Cloud in that state looks dead from a phone while the hardware runs, the EXT4 volume is untouched, and the shares still answer on the local network. Check the unit by IP address before assuming the disks are the problem.

My Cloud Home Stores Files as Hex Content IDs

My Cloud Home and My Cloud Home Duo are a different architecture from the classic My Cloud NAS described above, and the difference shows up after the image is already in hand. User files are stored under machine-generated hexadecimal content identifiers with the original names, extensions, and folder hierarchy stripped out. The mapping back to real names and paths lives in a separate SQLite index database, index.db, on the drive itself.

So an image of a Home drive reads fine, but it's useless as it is: hex-named objects with no extensions and no directory tree. Making it usable means parsing that database and re-mapping the objects back to their names and parent folders. The Home Duo carries the same framework across two drives. It defaults to Mirror (RAID 1) with a Max Capacity (JBOD) option, so how many members the offline rebuild needs depends on which mode the owner picked.

That is a separate workflow from mdadm superblock reading, and it has its own writeup on the My Cloud Home recovery page. Multi-bay classic units stay on the array path shared with the rest of our Linux NAS recovery work.