The ReadyNAS 312 – A new hope

Note: This is part 4 of an ongoing series. For earlier posts in this series, see the ReadyNAS 312 tag.

The findings so far …

Before diving deeper into this, let’s sum up the important findings so far:

• We have a Netgear ReadyNAS 312 which is decent hardware, but in lack of software-upgrades will become obsolete e-waste.
• We have not only found a concealed serial-port, but also the pin-out and the port-configuration.
• We are very optimistic about what this will enable us to do.

We now have a new hope.

A change of pace

This post starts with what one could consider both a teaser and a disclaimer:

So far we’ve only been probing around, building up an understanding of how this unit works. We have not in any capacity fundamentally altered anything or made significant changes to either the hardware, software or configuration.

The discovery of the serial-port changes this. We’ve learnt a lot of things. And now we have the “god-mode” we need to employ that knowledge into meaningful changes.

From here on out, we will be carefully making changes, test what works and what doesn’t, and make a final plan for how our new “god-mode” powers can allow us to save this unit, to properly repurpose it.

If you are planning to do something similar to a ReadyNAS of your own, make sure you fully understand what we’re doing, and what the consequences of doing that is.

Making mistakes is human, all failures have a degree of uniqueness and you may need to be able to revert previous changes without explicit instructions detailing how provided here or elsewhere.

And with such web-legalese out of the way… Let’s get going!

The serial-port 101 (part 2)

When working with appliances of different sorts the term “rooting” is often used to denote taking over control from a locked down firmware. Technically speaking it means getting control of a root-account within a running system.

With the ReadyNAS with didn’t have to go rooting at all. Getting root-access was even documented!

Our problem is that root-access only gets us control and access within the currently running operating-system, but we wanted to replace that with something else altogether.

While root-access can be used to obtain further access, it can only do so from within the confines of the currently running system and this typically takes a lot of effort and planning. And if you make a mistake in your execution and corrupt the system so it no longer starts… Your root-access will be gone along with the system no longer booting. You’ve bricked your device.

Ideally we want reliable control of how the unit boots. Then we need access outside the operating system, access at a higher level than root. We need machine-level access.

And this is what the serial-port very often can provide for us.

Basically this single finding gives us the safety and confidence we need to be way more adventurous! And now things are going to be moving forward at a much faster rate. Or at least so we hope!

So just what does the serial on our ReadyNAS 312 get us?

It’s time to find out!

A quick project reboot

We ended our last post inside Minicom, connected to the console of ReadyNAS OS, with a Linux login-prompt blinking in our face.

The first thing to check is obvious: Does our root login still work as expected here?

And yes, it very much does.

On embedded devices like routers, serial access often goes all the way down to the firmware bootloader, giving us effectively unrestricted access to the device as a whole.

But this is an Intel-based device, with a traditional AMI BIOS. Will we be as lucky, or will serial just be enabled once BIOS has passed control to the kernel in place?

There’s only one way to find out!

Yup. We’re literally going to reboot the device to gain the insight we need to reboot this project, this time from an outside looking in approach.

Wait wait wait. Is the BIOS itself serial-enabled? It sure looks like it! That’s about the biggest jackpot we can score!

Full BIOS control, connecting some dots and our first real facepalm

Sometimes you have to be told something you already knew in order to realize the obvious.

And at this point, from inside BIOS, that’s just what happened for me:

• In part 1, by using lsusb I determined there was a hidden flash volume inside the unit, from the kernel seen as /dev/sdc.
• In part 2, I discovered that the running ReadyNAS OS firmware actually resides on our data-drives, but containing no boot-code. So I hypothesised that the boot-code had to be on the hidden flash volume.
• In BIOS we get this confirmed. The ReadyNAS is booting from the flash volume… which wait… is a USB device?

So not only is the ReadyNAS (which has 3 USB ports btw) capable of USB booting, it is actually already USB booted.

How on earth did I miss that?

A facepalm. Probably the first of many to come.

So now, armed with BIOS access, we might be able to simply boot Debian from an external USB drive, no messing with the existing ReadyNAS system at all.

That almost sounds too good to be true. Let’s press F2 at the appropriate time and find out!

After some testing reveals, it’s not quite that simple, but we still have something workable. Here’s what you need to know:

• In BIOS the internal flash volume is by default set as pri #1.
• It’s also pri #2, although that’s for UEFI boot. (This BIOS supports UEFI too!)
• Pri #3 is one of the NAS volumes (P0), which we know isn’t bootable.
• Seemingly that’s all your options, but if you go to the boot submenu “Hard Disk BBS priorities”, you can swap out P0 for a USB drive of your choice (but as usual only as long as it was inserted when you entered BIOS).
• After doing this, you can assign your USB-drive pri #1, and it will boot.

That pretty much sounds like case closed, or what? Nooooo… There’s one very important pitfall to be aware of:

After being powered off, the ReadyNAS BIOS will revert to its initial boot priorities!

So unless you want a serial console to be required to boot your custom Debian install, we have no other choice: we will have to overwrite /dev/sdc with our own /boot partition and boot-loader.

And if you do that, uhm, you’ve sorta passed a point of no return. Well at least almost, unless you’ve prepared some backups.

Keeping it safe and boring

From what we’ve learned so far, the ReadyNAS unit depends on the following volumes to boot and operate:

• 250MB internal flash volume. May be exposed as /dev/sdc, but not guaranteed to be so from another booted USB drive. If in doubt, check in dmesg!
• ReadyNAS OS firmware-volume. in my case exposed as /dev/md0. This partition should be around 4GB.

The simplest way to back up small volumes like that is using a tool simply called “dd“.

But since /dev/sdc is concealed from us from within ReadyNAS OS, we’ll need to USB boot into another Linux distro, like a Debian Netinstaller to get access to it for backup purposes.

It really is as imple as that, with just one exception: We need to make the Debian Netinstaller serial-enabled first! Luckily for us, someone else has already described exactly how to do that.

Make sure to keep the same kernel command-line parameters as we’re already using. That is: tyyS0,115200.

Once you have your modified ISO, write it to a USB-stick using dd, insert it into the ReadyNAS, reboot, enter BIOS, and ensure your USB-stick has the highest boot-priority.

If you’ve done everything correctly, on next boot you should be greeted by a Debian installer.

After all this work, that really feels amazing, doesn’t it? It sure as hell feels well earned.

Exit to a root shell and identify the flash drive to backup:

sudo dmesg | grep logical
...
...
[ 6.629953] sd 6:0:0:0: [sde] 489472 512-byte logical blocks: (251 MB/239 MiB)

Notice how the /dev/sdc block-device’s name may differ when booted from another USB device outside ReadyNAS OS! For example in the log above, we can see it exposed as /dev/sde.

If you have another SSH-enabled host on the network (and ofcourse you do!), backing up the relevant partitions is dead simple:

# backup boot-partition
sudo dd if=/dev/sde | ssh user@backup-host dd of=readynas-flash.img
# backup readynas-os rootfs-partition
sudo dd if=/dev/md0 | ssh user@backup-host dd of=readynas-md0.img

Tip: This technique is often be used to copy out large data from inside firmware on embedded devices (like routers) which has little to no internal storage.

So now… We know how the device works, we have made our backups.

There’s only one thing left to do!

Let’s dive into that in the next and possibly final post!

(Continued in part 5)