Alternative Firmware (Debian Jessie, Synology DSM6)


Hello @Fox_exe . Thanks a lot for your firmware.

I was using your firmware for clean Debian jessie on MyCloud Gen2. Then I upgraded it to stretch and kept the old sshd config file. However, after reboot ssh didn’t recognize the same password. So I tried to inspect the issue by booting from your USB image, which worked before the upgrade. However MyCloud couldn’t boot from USB anymore. Now I have a clean Debian stretch but completely lost it access.

Do you have any idea why the USB boot is lost and how I can rescue it please?


Managed to boot from USB using the image in a different thread:

Still no idea why.


Hi you all i am a litle confused.

I have a ex2 ultra.

Can i install the DSM (DSM-wdmc-mirror-gen2-8451.pat) on this or not.

I have a problem with the arcus sotware on the ex2 and hope to solve this with the surveillance software of the DSM

Regards Wim


@wvdbroek, Nope - need different dtb in kernel. But all other - same for all armada-based devices.
Maybe i continue developing on holidays.

For now - i make dtb for latest kernel (4.14.x) for WD MyCloud Mirror Gen2 (Debian Stretch and Ubuntu Xenial available for this device too)



When installed DSM to WDMC Gen2, do you get full features of DSM, like quick connect, cloud sync, photo backup from iphone and other cloud services?
My WDMC Gen2 8Tb currently ■■■■■ in every way since I purchased it. Since I cannot return this white garbage box and get money back i’m considering to switch to alternative firmware.


@Justase, No, for “Cloud” features - need valid SN+MAC pair, provided as kernel startup parameters.
Allmost all other stuff works perfect.


Oh well :frowning: I’ll need to speed up current system by disabling unwanted services in this case. I really need cloud services


@Fox_exe I’d disagree with ‘perfect’ at least for the DSM part;)

Are the non DSM versions (Linux) more stable?



@Rand, i run Debian linux on my Gen2. Works perfect ~2 years. All configured “by hands”. No web-gui or similar tools. Only console, only hardcore! :smiley:
Ubuntu on Mirror Gen2 works perfect too (~1 year. Last week - with latest kernel v4.14.6 - no problems).

What i use on my gen2:

  • Nginx (Web-server and my website /
  • SyncThing (For remote access to my files and sync few folders between devices)
  • Transmission (Torrent-client / downloader)
  • MiniDLNA (Media-streamer for TV)
  • C/C++ buld system (Build some tools, repack apkg for official firmware, build software for Gen1 and many other things)
  • Git server.
  • Minecraft server (Yeah, im crazy! But its works good. For ~10 players).


Hm good to know.
Whats the power draw with linux for you? Running linux would basically put it en par with a RPi from a functionality pov (for me). Not really what I intended originally for it:stuck_out_tongue:


WD Gen2 consumes:
Idle: 5-6W
Typ: 8-10W
Max: 20-25W


Hey @Fox_exe, nice work! Thanks for all the effort :smiley:

However I’m having some issues with your fw_packer tool. It reports the right sizes and offsets in the console output:

Analyzing file "My_Cloud_BVBZ_2.30.174.bin"...

Firmware header data:
Section|     Start |          Size |           CRC
Kernel         128         4093284      -1859448386
Ramdisk    4093412         2222324       480142426
RootFS     6315736       102758400       102756352
Config   109074136           16832       455653699
Build version:
Build product: GrandTetU

However the output files are not correct:

-rwxrwxrwx 1 root root      1367 Dec 29 09:17 config.tar.gz
-rwxrwxrwx 1 root root 109098876 Dec 29 08:37 My_Cloud_BVBZ_2.30.174.bin
-rwxrwxrwx 1 root root      2105 Dec 29 09:17 rootfs.cfs
-rwxrwxrwx 1 root root       409 Dec 29 09:17 uImage.bin
-rwxrwxrwx 1 root root        85 Dec 29 09:17 uRamdisk.bin

I’ve tried looking into the code, but my C/C++ knowledge is quite limited, so I could not find the root of the issue. Could you please help me out a bit with it? :slight_smile:


Hmm… Strange.
You build tool from source? Try precompiled binary (On device).

I’m update source/binary:

  • Much faster file split function (Faster unpack process)
  • CRC in HEX value
  • Output file size checking
  • Cosmetic changes
  • TODO: CRC Checking and back-packing (Firmware build/pack) function


  • WDMyCloud Gen2 / Debian stretch - ARM (armhf) version
  • Regular PC: Ubuntu Xenial (x86 and x64)
  • Regular PC: Windows 10 x64 (x86 binary / Console app)
  • My_Cloud_BVBZ_2.30.174.bin
  • My_Cloud_KC2A_2.11.168.bin
  • My_Cloud_LT4A_2.11.140.bin


Yes I did. In the meantime I’ve even made my own tool, written in C# (bit easier for me to understand). The CRC shouldn’t be in hex, if I’m not mistaken it’s regular Crc32C (not sure about this though).

Repacking should be easy, just use the sizes + start position after header (which should be fixed if I’m not mistaken, to 128) to calculate size, then calculate CRC, and done.

Though I’m not a 100% sure that the header is fixed size - there’s a reason why they used a separator, so it is possible that more than the four currently used kernel objects can be added. The separator is there so that the reader can recognize when to stop processing entries (basically - read length until 0x55 0xAA, divide by three (since all entries have a start, an end, and a CRC), from there, assign the appropriate arrays, etc.

I also had the idea of making a brand new, clean firmware that does not necessarily require the HDDs to be in place, but rather contains a small installer that has error handling, web UI, et cetera - basically it would work similar to Synology’s solution, but a more pure approach with e.g. Debian + OMV (though I’d prefer Ubuntu then). Even the current Debian install could be modified, I think, into something automated, to an extent.


Made some progress on discovering the firmware. So basically the header is fixed 128 bytes (at least so far).

First segment is the data blocks definition:

  • 4 bytes for kernel start
  • 4 bytes for kernel size
  • 4 bytes for ramdisk start
  • 4 bytes for ramdisk size
  • 4 bytes for rootfs start
  • 4 bytes for rootfs size
  • 4 bytes for config start
  • 4 bytes for config size

Then comes the CRC:

  • 4 bytes for kernel CRC
  • 4 bytes for ramdisk CRC
  • 4 bytes for rootfs CRC
  • 4 bytes for config CRC

We’re at byte 48 now. 2 bytes follow up (delimiter, 0x55 0xAA), then the model/platform name (I’d guess latter since it repeats on different models that are actually the same board), which is fixed 8 characters long (padded to end with 0x00 if shorter). Then again the delimiter. Position is at 60.

After this comes another device identifier magic, 5 bytes. 0x00, 0x14, a device (generation? model name?) specific value (0x00, 0x01, 0x02, etc.), 0x01, 0x01. Apart from the third varying value, the rest seems kinda magic value-y to me.

So we’re at 65 of 128. This block is followed by 55 characters, the version (as mentioned before), plus 0x00 padding to 55.

The interesting part is after this. 8 bytes, of which the single last byte matches in every firmware.At 0x7F, in every firmware, regardless of what the other 7 bytes are, is 0x06. The rest changes between the same device’s firmwares, and even basically the same firmwares (e.g. MyCloud Mirror Gen2 and EX2 Ultra) have different values there!

I’m currently stuck at unsquashfs-ing the rootfs, I’m getting a no superblock found error, but might be my extraction.


Okay, I dug through the thread, it took some time.

@Fox_exe I think you should update the descriptions in your folders - tons of old/false info there which makes things harder. Especially on the EX2 Ultra front.

As for the syno file corruption… It’s an intended “feature”. Synology has introduced stricter and stricter checks to make sure the OS will only run properly on their own hardware. The XPEnology project, while completely different, is a good starting point for that. Nearly all of these are well documented on their forums, albeit they require some digging. The harder part? All the current patches are, well… Closed source. But if anyone feels like tinkering around, this is the patcher that fixes stuff. 140kB, so not small, tons of code, but you can figure out the rest :wink:

And as for my NAS… Looks like I’ve temporarily killed it, at least as long as I can get an FTDI USB cable. Oh, did I mention that I took a closer look at the board, and the small PCI-like edge connector on top is actually connected to TX, RX and GND? So as long as the board is powered, a simple adapter can be slipped onto it and used for debugging, no need for soldering or taking it apart. The pins are as follows (when the single prong is on the right, i.e. the “bottom” picture):

  • First pin is ground
  • Middle pin is Tx
  • Third, rightmost pin is Rx

The single standing pin is not connected, at least not in a visible way, but one would guess it is (supposed to be) the 3.3v interface.


Firmware header structure (From my unpacker):

4 bytes kernel_start;
4 bytes kernel_size;
4 bytes ramdisk_start;
4 bytes ramdisk_size;
4 bytes rootfs_start;
4 bytes rootfs_size;
4 bytes config_start;
4 bytes config_size;
4 bytes crc_kernel;
4 bytes crc_ramdisk;
4 bytes crc_rootfs;
4 bytes crc_config;
2 bytes delimeter1;		// 0x55AA (Sepparator? Magic?)
8 bytes codename;		// Glacier + 0x00
2 bytes delimeter2;		// 0x55AA
1 byte ver_1;			// 0 = (int)0	// Product
1 byte ver_2;			// 14 = (int)14	// Custom
1 byte ver_3;			// 2 = (int)2	// Model	// Found values: 0=Ex4 (Lightni), 1=Ex2 (KingsCa), 2=Gen2 (Glacier)
1 byte ver_4;			// 1 = (int)1	// Hardware
1 byte ver_5;			// 1 = (int)1	// Sub
55 bytes ver_full;	// 18 byte actually:, but ends with zero, so i dont care.
4 bytes next_header_crc;
4 bytes next_header_offset;

CRC calculator and other cool stuff you can find here: Github/michaelroland


Ah, dangit, missed that bit. Thanks!

I’ve ported the CRC calculator to C#, and I think in the following days I’ll have a full solution for firmware packing-unpacking.

It would also be nice if you used GitHub for hosting your source code bits, easier to see the changes :slight_smile:

Also for anyone who’ve got the same trouble as I (installing DSM 15047 bin and not having UART to restore), run the installer until you get to Error 13, then you can telnet in - the username and password are root/mycloud.

However I think I borked up things. Wanted to go back to WD original firmware for some tests, so I wiped /dev/md1 and /dev/md2 - now Safe Mode boots, but it misses a sysmgr.cgi or something similar, and even the upload won’t start. Looks like I gotta hook up that UART cable I ordered…


Dear, greetings.
I am considering installing OMV or DSM on my WDMyCloudMirror (GEN1), but I can not take much risk with the device in question, and frankly, I could not determine, in this forum, if all the problems for this specific model have been solved

So, I ask those who have actually installed OMV or DSM in WDMyCloudMirror (GEN1), whether they can tell you if the device works without problems, or if there is still a bug to be handled.


@psidrj, OMV works great. Fast and smooth.


Thx, Fox