The beginning

I recently purchased a Synology DS1803+ DiskStation for the drives it came with. After using the drives for another project, I was stuck with the DiskStation. Because of Synology’s DSM, a slimmed down Linux-based OS I meant to be managed through a web UI I really had no use for it. I couldn’t install the software I wanted, constantly feared breaking something, and was stuck with a myriad of services I did not need.

One day, I was preparing for work and thought about installing Debian on it. After a quick google search, I found a page on the Debian wiki detailing the installation of Debian on an ARM-Based Synology NAS. Mine is based on the Intel Atom d2701 x86 CPU. The guide would not help me, but the idea stuck with me.

Taking a look at the hardware

The front, rear and sides of the NAS don’t really look too promising. No display connector, no serial port, only network, eSATA and USB. Rear of the NAS While taking the top cover off, I noticed an interesting black rubber grommet on the right side of the NAS. Removing it revealed a 2x3 pin 2 mm pitch pin header. Bottom of the NAS Picture of the console port

I didn’t know the pinout of the header, and didn’t want to google it because that is no fun. Unfortunately, I didn’t have any jumper cables with a 2 mm pin pitch, only the standard 0.1in pitch. To connect to the pins, I removed the top cover and the motherboard. This would be a necessary step in any case, so I didn’t mind. The motherboard next to the rest of the NAS I soldered long pins to each of the pads on the motherboard and connected a logic-analyzer to each one of the pins. I didn’t even multimeter anything, I didn’t really feel like it.

Getting a console

Jumper leads connected to bodged pins on the motherboard

I started using a PicoPSU instead of the regular PSU and put the motherboard on top of the case, insulating it with some cardboard I had lying around. This was so I could access both sides of the motherboard without being obstructed by the case. I couldn’t put the motherboard anywhere else because the cable connecting the front panel to the motherboard was too short. I just removed the front panel and put everything on my desk later on.

The logic analyzer I used was a cloned Salae Logic 8 I got off eBay, I used Salae’s Logic2 software on Debian Sid.

After booting the NAS, I could see some change on three channels of the logic analyzer. Channel1 looked like it was sending data. Screenshot of logic analyzer software showing data on one of the pins I enabled the serial decoder plugin and tried 9600 and 115200 baud. These are the settings that worked fine: Settings of a serial decoder plugin in the logic analyzer software Looking at the decoded data, we can see that we’re in some sort of BIOS. The hex values in between the text are color codes. Screenshot of decoded data on the serial port

We now know what TX of the console is. We still need to find GND and RX.

I used my multimeter and just beeped through the remaining five pins to find GND. I’ll give you a pinout later on.

RX was a bit more tricky since it does not send any data. Having some faith Synology’s engineers, I tried the pin next to TX and… Bingo! My serial console was working. I tried it by hitting Ctrl-C in the bootloader as prompted and seeing GRUB react. I could’ve also waited for it to boot completely and try to enter something in the “username” field prompted awaiting user login.

Screenshot of the BIOS This is the pinout when looking at the console port with the disk-side of the NAS facing down:
FAN / port side
Far edge of the case N/A GND Close edge of the case
Far edge of the case N/A TX Close edge of the case
Far edge of the case N/A RX Close edge of the case
Disk side

Discovering the boot process

While the NAS is booting, you’ll be prompted to hit CTRL-C to stop booting. This is prompted by a lazily cut-down version GRUB 0.97. Half of the normally available commands are half-heartedly removed, and some crash the NAS. More about this “Synoloader” later.

The firmware Synology has installed onto this box seems to be a fairly reference-like implementation of some PDK(?). Among other things, Synology has disabled the EFI mapping any storage device that does not have a specific Synology vendor ID. This effectively means that the EFI will not detect any storage device not made by Synology. Just plugging a USB drive into this thing and booting off it was a naive dream of mine.

The daughter board with the DSM sticker is the flash it tries to boot off: (Please ignore the dust, the NAS was apparently running for a couple of years) ((Also ignore the pins sticking out of the motherboard, I took that picture at a later stage of breaking this thing)) Picture of motherboard with flash dauther board

Removing it will drop you into a cut-down EFI shell. No network stack, half the commands you’d expect from an EFI shell are missing. A bad time overall.

I wanted to access the data on the flash to try and learn more about the boot process. To access the flash, I needed to know the pinout of the flash. I assumed it was USB, but wasn’t sure and couldn’t really afford to break the flash because I literally couldn’t use the NAS without it.

After a bit of probing around, it turns out that the header the flash connects to literally has the same pinout as a normal internal USB2 header.

I tried to connect the flash to my PC by soldering a USB-B port to the flash. When that didn’t work, I tried some other things.

It was getting late, I didn’t really read the datasheet of the flash controller in too much detail, didn’t check that the port I soldered onto the header was connected properly and assumed the drive was using eUSB and not USB. eUSB uses a lower signal voltage and I thought the drive was not showing up because of that.

Long story short, I transplanted the flash chip onto not one but two different USB-Drives that I had on hand and had the slightest chance of compatible with the flash chip. Tinkering around with the MPTools (MP = mass production) of the controllers only yielded disappointment because the flash was incompatible. I didn’t really take many pictures since I initially wanted to leave that part out. I do have this one, though: Picture of flash chips next to a USB drive and the flash daughterboard There’s also this abomination: Picture of oscilloscope probes connected to the motherboard

As it later turned out, I accidentally messed up the order of the data pins. I just soldered a normal USB cable to the flash, you can see the pinout of the module by comparing the colors of the cable. All USB cables have the same colors.

Picture of flash module with USB cable

The controller of the original flash module is a Phison PS2251-68-5 and the flash is SAMSUNG K9F1G08U0E.

Connecting the device to a PC shows two partitions with the following content:

Partition 1
/
/EFI
/EFI/boot
/EFI/boot/SynoBootLoader.efi
/EFI/boot/SynoBootLoader.conf
/EFI/boot/checksum.syno
/rd.gz
/startup.nsh
/zImage
/FvUpdateSpi.efi
/GRUB_VER

Partition 2
/
/grub_cksum.syno
/checksum.syno
/rd.gz
/Sone.9
/vender
/zImage
/DONE.fd

The files /EFI/boot/SynoBootLoader.conf and /startup.nsh immediately sparked my interest. Startup.nsh is executed by the EFI and has the following content:

stall 1000

fs1:

if exist bios.ROM then

rm DONE.fd
mv bios.ROM DONE.fd
FvUpdateSpi.efi DONE.fd

endif

stall 1000
SynoBootLoader.efi
stall 2000
SynoBootLoader.efi
stall 3000
SynoBootLoader.efi
stall 5000
SynoBootLoader.efi
stall 10000
SynoBootLoader.efi
stall 30000
SynoBootLoader.efi

reset

“stall” is the EFI equivalent of “sleep”. It stalls the CPU for a given number of microseconds. The script basically checks for a firmware upgrade and installs it if available. Then it tries to chain load the modified GRUB executable called SynoBootLoader.efi.

Booting the NAS

Since I had access to the flash now, I could replace the SynoBootLoader.efi executable with normal grub and try to boot the NAS. I re-connected the flash to the NAS using the USB cable and not the header. I didn’t really want to mess anything up by having the cable act as a transmission line and letting the signals reflect back and forth. Screenshot of modern grub running on the NAS

Please execute the error messages, they are caused by a broken grub.cfg

Even though I had partially re-assembled the NAS and inserted an SSD with Debian, the bootloader can only find the flash module with the two partitions. This is because the EFI does not map the other disk. We have to put the initramfs and kernel onto the flash module to boot.

I re-connected the flash to my PC, simply re-created the second partition of the flash and formatted it as EXT4. I then copied the initramfs and kernel onto the new partition and wrote the following grub.cfg: set root=‘hd0,gpt2’ set timeout=5

menuentry 'Debian GNU/Linux' {
    echo    'Loading Linux 6.1.0-2-amd64 ...'
    linux /vmlinuz-5.10.0-21-amd64 console=tty0 console=ttyS0,115200 root=UUID=8f26fd1b-7678-4083-88e4-bac902974d9c ro
    echo    'Loading initial ramdisk ...'
    initrd /initrd.img-5.10.0-21-amd64
}

I put the config under (partition1 of the flash)/EFI/boot/grub.cfg I put the initrd and vmlinuz in the root of the second partition of the flash. The “set root=” command tells grub to interpret the second partition of the first disk as the current directory. As no other devices are mapped by the EFI, this is always the Synology-flash.

After this, I just had to re-boot the device, and it just worked. Debian booted right up.

I haven’t really made this proper, Debian can’t update the grub config, the partition is never mounted, and I’ll have to manually replace the initrd and vmlinuz files every time they need to be updated, but that should be relatively easy to fix. Here’s a video of the full boot process. I filmed it before writing the grub config to the config file, so I just copy-paste the commands.

Overall, I am just overjoyed this thing is not using secureboot only accepting a bootloader signed by Synology.

Here’s a copy of the original flash should you need it: synology-flash.bin