My Cloud PR4100 Firmware Analysis


dude, keep it up. I find it very enjoyable reading about what you have discovered.

I say 100% thank you…please keep it up. or send to me privately.


aww that’s really unfortunate… I enjoy reading this thread and I’d like to contribute. I got my PR4100 just this week but I’m ready to get my hands dirty :slight_smile:


Hey mate,

I have actually found all this an interesting read and also on the bits on recovery of your unit via USB. I’ve actually got an EX4100 and not the same model as yours but do definitley find this interesting none the less.

Thanks for putting this together and if you do decide to change your mind on it, I’m happt to look over the EX4100 and offer similar insights.




This thread has been one of the most enjoyable reads I have encountered in a forum. A lot of what you have posted is above and beyond my level of expertise. However, I get the idea and was checking up on your findings with regularity. I would absolutely love to continue reading abut your findings. Please reconsider and continue with the updates. I own the PR4100 which I use primarily for PLEX and have no problems with it in this respect, but agree the firmware is a disaster when compared to the flexibility of my Synology NAS.


@dswv42 you gave some examples about mounting wd_config but did you make any changes to the squashfs yet?
What happens when it doesn’t pass the CRC check on boot (in case you would’nt update the CRC)?


Yes, I’ve made changes to the SquashFS (image.cfs) file, but that’s an integral part of the firmware build process. I’ve also built and tested custom kernels, etc…


I’m currently going through the hell of building the open source packages… Would you mind sharing your scripts via PM to save me some time? Doesn’t matter if it’s incomplete or a bit crude, but I don’t like going through this mess knowing that someone has cleared the path before :slight_smile:

I’d like to install OMV or plain debian on this box… 2 GB flash is sufficient as system disk, I just need to setup the logcollection to be RAM only. I have the USB-TTL cable and GRUB access but I intend to create a headless installer (iso with preseed config).
My main issue now is the fancontroller… it is spinning at full speed. lm-sensors is not able to relax the fan with PWM.
Then I tried to copy wdtmsd (wd thermal monitor svc daemon) with all its dependencies but it fails to insmod /opt/wd/kmodules/rstbtn.ko … any way to build this myself?


Building packages and/or installing a different OS is tricky business, largely because there are so many different variables one must take into consideration. Likewise, some of the hardware (fan, display, etc) seems to be controlled with compiled binary files, where WD conveniently neglected to provide the source code.


I got around the failing insmod by using a forced modprobe. However I realized all my efforts may be wasted on the reset button (rstbtn.ko), an I2C button like here.
The reset button is not that important to me…
I want the WD hardware service daemon (wdhws) and other binaries in /opt/wd/bin such as temperature monitor (wdtms) and power monitor in my other kernel.

@dswv42 Did you get the WD temperature and power management binary blobs working in your custom kernel?

I copied all the files used in the /etc/init.d/S14wdhws script and the wdhws logs in syslog

wdhws: starting wdhw service with config_file=/etc/wd/sprite-wdhw.xml
wdhws: wdhw_service
wdhws: start
wdhws: launch
wdhws: run

However it shuts down without any error or warning :frowning:
The other services need the wdhws to be running…

ldd /opt/wd/bin/wdhws

Shows that all libraries have a match, however most of them come from the newer kernel.


Yes, but only if the kernel version was the same, or very close. Newer kernel versions caused some issues, but I don’t recall specific details. I’ve been busy with other things and custom firmware has become a low priority.


Some info for those who want to rewrite the image.cfs

  • the image has a 2048 bytes header, all zeros except for the initial 8 bytes
  • first 4 bytes is the size of the actual image
  • second 4 bytes is the checksum, more precisely a XOR of all 4 byte chunks.
  • in other words, now you know what firmware/module/image_checksum does
  • mount the ext4 volume first to some location
  • then mount the squashfs image on that volume with an offset to remove the header

mount -t squashfs -o loop,offset=2048


@dswv42 what are your thoughts on this:
You get to setup debian on a USB drive, chroot into it and eventually even boot into it.
It allows to go back and forth between stock firmware and the debian chroot.
In the chroot you can setup openmediavault to get cloud features while the WD services can be killed (except the ones from /opt/wd/bin). You could even create a ZFS setup.


I haven’t personally tried it, but see no reason why it wouldn’t be possible… as long as the kernel is compiled to run on the hardware.



I have an EX4100 and would like to try and help out here if I can. I am running out of patience as well with the issue a number of EX4100 users are exhibiting whereby the NAS will kernel panic and lock up for no apparent reason. I’ve implemented a workaround on my NAS but a reworked firmware would be a better option.

Let me know if there is a way I can help out.




I decided to see if installing another operating system on the PR4100 is possible. After much trial and error, I successfully installed Debian 8 (Jessie) & Debian 9 (Stretch), but not at the same time. As you can imagine, there is a trick to it, where the overall process is not as complicated as I had imagined. I also believe it will be possible to install uBuntu Server, but I have not tested it yet.

No changes to the factory firmware were required. The process is quite literally… plug and play.


While experimenting with Debian on the My Cloud PR4100, I discovered two additional NAND flash partitions which are hidden when running the stock firmware (My Cloud OS3). The first device /dev/mmcblk0p7 (wdnas_reserve1) is empty, but the second device /dev/mmcblk0p8 (wdnas_reserve2) contains an empty 1 byte file named hidden_encryption.

# blkid -o list

device              fs_type   label
/dev/mmcblk0p1      vfat      wdnas_efi
/dev/mmcblk0p2      ext4      wdnas_kernel
/dev/mmcblk0p3      ext4      wdnas_initramfs
/dev/mmcblk0p4      ext4      wdnas_image.cfs
/dev/mmcblk0p5      ext4      wdnas_rescue_fw
/dev/mmcblk0p6      ext4      wdnas_config
/dev/mmcblk0p7      ext4      wdnas_reserve1
/dev/mmcblk0p8      ext4      wdnas_reserve2
/dev/mmcblk0p9      ext4      wdnas_backup

# fdisk -l

Disk /dev/mmcblk0: 3.6 GiB, 3833593856 bytes, 7487488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Device                 Start           End       Sectors       Size       Type
/dev/mmcblk0p1          2048         73727         71680        35M       EFI System
/dev/mmcblk0p2         73728         94207         20480        10M       Microsoft basic data
/dev/mmcblk0p3         94208        114687         20480        10M       Microsoft basic data
/dev/mmcblk0p4        114688       2211839       2097152         1G       Microsoft basic data
/dev/mmcblk0p5       2211840       2293759         81920        40M       Microsoft basic data
/dev/mmcblk0p6       2293760       2334719         40960        20M       Microsoft basic data
/dev/mmcblk0p7       2334720       2355199         20480        10M       Microsoft basic data
/dev/mmcblk0p8       2355200       2375679         20480        10M       Microsoft basic data
/dev/mmcblk0p9       2375680       2416639         40960        20M       Microsoft basic data

# parted -l

Model: MMC P1XXXX (sd/mmc)
Disk /dev/mmcblk0: 3834MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start     End       Size      File system  Name          Flags
 1      1049kB    37.7MB    36.7MB    fat32        EFI System    boot, legacy_boot, esp
 2      37.7MB    48.2MB    10.5MB    ext4         kernel        msftdata
 3      48.2MB    58.7MB    10.5MB    ext4         ramdisk       msftdata
 4      58.7MB    1132MB    1074MB    ext4         image.cfs     msftdata
 5      1132MB    1174MB    41.9MB    ext4         rescue_fw     msftdata
 6      1174MB    1195MB    21.0MB    ext4         config        msftdata
 7      1195MB    1206MB    10.5MB    ext4         reserve1      msftdata
 8      1206MB    1216MB    10.5MB    ext4         reserve2      msftdata
 9      1216MB    1237MB    21.0MB    ext4         backup        msftdata

There also appear to be two additional devices, but they are locked and neither of them can be mounted. Research revealed that these appear to be boot partitions (MMC boot), and altering either of them could easily brick the NAS. Quote: mmcblk0boot0 is a hardware-defined partition in the eMMC distinct from the mmcblk0pN partitions that are defined by the MBR partition table in the “user area”.


Overall, Debian appears to run flawlessly on the WD My Cloud PR4100, except that the fan always runs at full speed and the front display is not functional. Various hardware control packages (fancontrol, etc) were tried, but none of them worked. Regardless, having the power of a real Linux distribution at my fingertips is certainly nice, especially when compared with the crippled environment that Busybox provides.



I just ran similar commands on the EX4100 and got the following:

root@WDMyCloudEX4100 / # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00500000 00020000 "U-Boot"
mtd1: 00500000 00020000 "uImage"
mtd2: 00500000 00020000 "uRamdisk"
mtd3: 1b900000 00020000 "image.cfs"
mtd4: 00f00000 00020000 "rescue fw"
mtd5: 01400000 00020000 "config"
mtd6: 00a00000 00020000 "reserve1"
mtd7: 00a00000 00020000 "reserve2"

So it looks like they also have reserve partitions here as well.

From /cat/proc/partitions:

major minor  #blocks   name
31        0       5120 mtdblock0
31        1       5120 mtdblock1
31        2       5120 mtdblock2
31        3     451584 mtdblock3
31        4      15360 mtdblock4
31        5      20480 mtdblock5
31        6      10240 mtdblock6
31        7      10240 mtdblock7

I’ll have to dig a bit more and see what is there as far as filesystems goes.




Good news, I’m on the virge of having the Debian install process fully automated to do a blind or headless install on the PR4100. I suspect that it may also work on other models, but I only have a PR4100 for testing. And believe me, learning the precise steps required, plus solving all the little problems that kept popping up, was anything but easy.

After more testing has been performed, I will create a guide so others may try it if they wish. The process is fully reversible, as long as a few common sense precautions are taken.



Do you need a console connection to the mainboard setup in order to do it ? I am gathering you would need to change the boot order to boot from USB rather then the Flash chip based on what I have seen posted on this so far.




A console connection is helpful, but certainly not required. In fact, no changes to the NAS are required at all. Well, all hard drives except for the installation drive must be removed…

By the way, I finally succeeded at fully automating the process. I just want to run a few more tests.