LaCie LaPlug

[mushupork]

Is anyone familiar with the new NAS device from LaCie? It is a small box and the drives it accesses are USB drives you connect. (like the Iomega iConnect)

I'd really like SSH access to the LaPlug. I see many subforums for LaCie products. Any idea if the tips for the other products will work for this one?

Thanks.

[Mijzelf]

Partly, maybe. There are big differences between this box, and the other Lacie's. The main one is that the NASses have their firmware on disk, while this one has its firmware in flash, putting more constraints on the size.

Anyway, I downloaded firmware 1.0.4, and had a look at it. binwalk told it's a tar file starting at byte 32. So I extracted it:

Code: Select all

dd if=plug_1.0.4.cluff bs=32 skip=1 | tar x

This gives 2 files:
-rw-r--r-- 1 Mijzelf Mijzelf 2090460 Nov 2 10:46 kernel.uboot
-rw-r--r-- 1 Mijzelf Mijzelf 40369564 Nov 19 11:35 rootfs.jffs2
obviously a kernel and a rootfs. Using the mtd2block kernel module I could mount the rootfs. Some findings so far:

• The box doesn't use initng, like other Lacie's, but system V init.
• According to /etc/inittab you can login on a serial port, 115200 baud.
• This box doesn't use the evil unicorn, instead there is something called 'klaxon'.
• There is an ssh server, and a start script in /etc/init.d, but it's not started directly by init.
• There is a telnetd server, and a start script in /etc/init.d, but it's not started directly by init.
• AjaXplorer is present, so you could try the symlink trick to get access to your rootfs.
• /etc/shadow contains much more users than /etc/passwd does.
• I think the box has a RT2860 wireless card.
• The box runs a 2.6.31.8 kernel

[mushupork]

The update procedure for the firmware is pretty straightforward. I am not skilled in this but my idea was to modify a firmware update and then apply the firmware with ssh enabled - or something similar. I could not figure out what to use to look inside a cluff file though to see if that was even an option.

This may sound naive, but could this be as simple as un-commenting /etc/init.d to allow ssh and/or telnet to start at boot in a firmware update and then apply that firmware update?

[Mijzelf]

Sound perfectly reasonable. I found the actual update function (it's in an uncommon place, /init):

Code: Select all

cluff_update() {
        FILE=$1
        FILE_LOCAL=$(basename $FILE)
        
        echo "*** updating with file $FILE_LOCAL ***"
        
        echo "- checking file"
        MD5_HEAD=$(head -c32 $FILE)
        FILE_SIZE=$(stat -c %s $FILE)
        TAR_SIZE=$((FILE_SIZE - 32))
        MD5_TAR=$(tail -c $TAR_SIZE $FILE | md5sum | awk '{print $1}')
        
        if [ "$MD5_HEAD" != "$MD5_TAR" ]; then
                exit_error "MD5 hash mismatch"
        fi
        echo "  => check ok: MD5 = $MD5_TAR"
     
        echo "- extracting files"
        EXTRACT_PATH=/tmp/files
        rm -rf $EXTRACT_PATH
        mkdir -p $EXTRACT_PATH
        tail -c $TAR_SIZE $FILE | tar -x -f - -C $EXTRACT_PATH
        
        if [ ! -f "$EXTRACT_PATH/$UPDATE_KERNEL_FILE" ]; then
                exit_error "missing kernel file"
        fi
        
        if [ ! -f "$EXTRACT_PATH/$UPDATE_ROOTFS_FILE" ]; then
                exit_error "missing rootfs file"
        fi
        
        echo "  => updating kernel"
        flash_write $EXTRACT_PATH/$UPDATE_KERNEL_FILE 2
        
        echo "  => updating rootfs"
        flash_write $EXTRACT_PATH/$UPDATE_ROOTFS_FILE 3
        
        echo "  => cleaning config and data partitions"
        flash_eraseall -q /dev/mtd4
        flash_eraseall -q /dev/mtd5
        
        echo "*** done ***"
        echo "- rebooting device"
        reboot -f
}

So a cluff file is actually a tarfile containing a kernel and a rootfs, preceded by a 32 byte md5sum of the tarfile.

There is a problem, however. the rootfs is a jffs2 image, which is a difficult filesystem. You can't just loopmount it, because it's intended to run from a mtd-blockdevice. With some tricks it can be mounted, but then it's readonly. (At least on my box it is). So the procedure would be copying the contents of the rootfs somewhere else, editing it as you like, and creating a new image from it using mkfs.jffs2. This last function needs a blocksize and an erasesize specified. AFAIK the blocksize isn't really important, but choosing the wrong erasesize could brick your box. So it could be a good idea if you managed to read /proc/mtd.
Maybe it's possible to extract the erasesize from the provided image. I don't know.

[mushupork]

Quick update ... The symlink trick worked.

I am now browsing the file system looking for default.runlevel so I can uncomment ssh.

[Mijzelf]

There is no 'default.runlevel', that's an initng file. This box uses system V init, and you should put a symlink S99sshd in /etc/rc2.d/ which points to /etc/init.d/sshd (or whatever it's name is). If you cannot create symlinks, you can copy the whole script to rc2.d. Rename it so it starts with S99 (The scripts are started in alphabetically order, and you definitely don't want to crash the init system too early.)

[Mijzelf]

When you can read all files in the filesystem, could you post the content of some interesting (pseudo-)files?
/proc/cpuinfo
/proc/meminfo
/proc/mtd
/proc/mounts
/proc/version
/proc/cmdline
/proc/partitions

[mushupork]

I am away visiting family but will check in once I return.

Before I left I did try copying an openssh script to etc/init.d and was unsuccessful in getting SSH to start. I did not see an "ssh" folder.

I have also been unsuccessful overwriting the password in the shadow password file to be able to login as root rather than admin. I think I overwrote the wrong part of the line for root though.

Again, ran out of time before the holiday to get these things done but will try again soon and post back.

[mushupork]

OK - the LaPlug is deleting the script file when I reboot the system.

I copy openssh to etc/rc.2, rename it to S99openssh and after reboot the file is gone.

Can I modify one of the existing files to include this info without corrupting them?

I attached a screenshot of what is in etc/rc2.d.

Laplug-etc-rc2.d.jpg

[Mijzelf]

I suppose you can edit /etc/init.d/boot for that (Is called as S99bootend). Change

Code: Select all

        bootend)
                /etc/usb/usb_power.sh status | grep 'off' > /dev/null 2>&1
                [ "$?" != "0" ] && /etc/leds solid blue
                ;;

in

Code: Select all

        bootend)
                /etc/init.d/openssh start
                /etc/usb/usb_power.sh status | grep 'off' > /dev/null 2>&1
                [ "$?" != "0" ] && /etc/leds solid blue
                ;;

Make sure you use an editor which handles *nix line ending well.

[mushupork]

Using the web interface I downloaded a copy of the boot file. I then modified it using pspad. I renamed the original boot file on the LaPlug to "boot-original". I then uploaded my modified boot file and rebooted the LaPlug. The renamed boot file "boot-original" is missing and the boot file that remains has the old time stamp that matches all the other files in the directory.

I suspect that the LaPlug is reinstalling the OS kind of like a Live CD when it is restarted. Not sure if that makes sense though - but it would explain what I am seeing. The openssh file I copied before and the boot files I just modified and copied are not being deleted specifically - the whole OS is being refreshed which makes those new files disappear and makes modified files the same as before the modifications. (From a product design or engineering standpoint that would probably be simpler than scanning the disk for changed files and removing or modifying them)

[Mijzelf]

That is perfectly possible. Actually all Lacie NASses use a unionfs to keep the modifications seperated from the 'real' firmware. This makes it possible to do a factory reset. Just delete the contents of the top layer. On other NASses the top layer is on harddisk, but it could be a ramdisk on the LaPlug.

The contents of /proc/mounts should be able to tell if this is the case.

Maybe there is another way to start ssh. According to /etc/udev/rules.d/external-disks.rules a script /etc/usb/disk/udev_clbk.sh is called when a harddisk is connected or removed. This script doesn't exist. But you can create one, and put

Code: Select all

#!/bin/sh
/etc/init.d/openssh start

inside it. Then, by inserting or removing an usb stick, the ssh server should be started.

[mushupork]

/proc/mounts has a single line that reads:

rootfs / ro

[mushupork]

/etc/usb/disk/udev_clbk.sh does exist on my LaPLug. It has a date and time stamp like all the other system files of 2011/05/20 07:35.

The contents of the file are:

Code: Select all

#!/bin/sh

flock -x /var/lock/usb-disk.lock sh /etc/usb/disk/core.sh udev "$1" "$2"

#(
#   flock -x 200
#   sh /etc/usb/disk/core.sh udev "$1" "$2"
#) 200>/var/lock/usb-disk.lock

[Mijzelf]

/proc/mounts has a single line that reads:

rootfs / ro

*That* is strange! You read this through a symlink on a USBstick, right? In that case at least the mount of the stick itself should be visible.

/etc/usb/disk/udev_clbk.sh does exist on my LaPLug.

Hm. that means that either there are more filesystems than the rootfs alone, or it's create runtime, somehow (why?), or my rootfs is damaged by mounting it with the wrong erasesize. Can you post me /proc/mtd to check out the first and last possibility?

The contents of the file are:

Well, you can just add the line

Code: Select all

/etc/init.d/openssh start

at the end. This script is called at each adding/removing of a USB mass storage device.