DSM-G600, DNS-3xx and NSA-220 Hack Forum

thanks for your explanation and efforts Mijzelf.
Yes I read the post on your trials with the reloaded kernel module. That would be indeed a solution as well, although I do not care about the warranty. A longer boot time is also no problem I think. I am looking forward to try out your solution.

I understand why zyxel has put the firmware in flash as the device is delivered without hard disk. But it is much more flexible to have the kernel and root fs on disk without the need to extract it everytime at boot. Also more space is available for fancy features and bigger kernels.
Maybe still someone can tell if it is possible to change the bootloader so that it directly looks to a partition to load the kernel and mount the root fs and forget about the version in flash.

I know the Lacie's, I even have written a home made firmware that runs on the Lacie network space and Philips spd8020. Two very cheap low end boxes. This with a detailed guide how to exchange the disk. The structure they have set it up is relative easy. They are available for dowmload, just google convopit forum. You can find them in the computer sub forum. Jippiejajee=fvdw.
You are right you need some linux knowledge to get the partition structure right and write the images.
The beauty is it is easy to hack and no risk to brick the nas as the bootloader remains untouched, if it fails just pull out the disk and connect it to a pc running linux to correct the error, also they boot faster, to be honest I find these flash based boxes much more difficult to hack.
Anyhow indeed both probably have there pro's and con's.

Maybe you're interested in the fw 3.12 upgrade (ftp://ftp.zyxel.com/NSA-220/firmware/). This one is done by a script on usbstick, which repartitions the flashmemory, and flashes it.

About initrd.bin; When you download and install the gplsources (ftp://opensource.zyxel.com), it will generate a complete firmware for you, including the rootfs.

I have experimented with copying the contents of mtdblock1 to usbstick and booting from it, and have been trying to create a unionfs of flash with a rw-layer on stick or hd. In both cases it works more or less, but the zyshclient doesn't seem to like a rw rootfs. At boot the user administration is read from flash, and converted to linux configuration files (a ramfs is mounted on /etc), and those ended up garbaged. So no samba, and no way to login on the webinterface.

just google convopit forum. You can find them in the computer sub forum

I can't find it. There seems to be no computer subforum.

also they boot faster

I don't think that it has something to do with booting from flash. When you look at the bootlog you'll see most time is consumed by mounting the raid array (reiserfs in my box), and converting user settings (which AFAIKS is done from ram to ram).
The firmware is just more heavy, and zyshclient is not designed for fast booting, I think.

status

found out how to extract the rootfs from the firmware bin file, adapted the rcS script to execute an additional command file from a location that I like, and to make a new bin file out of it.
The initrd bin file is squashfs  file system that contains the root filesystem.
With thanks to zyxyl to put the necessary binairies (intel 386) in the source files to unsquash and squash it.
So now need to double check the commands to write it to flash..and see what happens.

Last edited by fvdw (2009-12-28 14:47:53)

samba is running ok as well after the second boot..

Assuming you are using my scripts, it's all done in /e-data/md0/ffproot/after_booting.sh.
On boot usbstick/usb_key_func.sh copies itself to /tmp, where it starts polling for fadd to be started. (In fw 2.10 that was the last program to be started in rcS). So when fadd is started, the box is up, and the disks mounted. When /e-data/md0/ffproot/after_booting.sh it will execute it, and else usbstick/after_booting.sh

The function chroot does it. It creates a virtual root, and executes some program in it. The syntax is

chroot new_root_dir command_to_be_executed_relative_to_new_root

All those 'mount --bind' are necessary to make the directories accessible from within the new root. The whole action is necessary because / is readonly, so I couldn't create an /ffp directory.

In your case I'd add a empty directory /ffp to your rootfs, and add the lines to rcS:

mount --bind /e-data/md0/ffproot/ffp /ffp
# run fun_plug local, if present
if [ -x /ffp/etc/fun_plug.local ]; then
    /ffp/etc/fun_plug.local
fi
 
# run commands
if [ -x /ffp/etc/rc ]; then
    /ffp/etc/rc
fi

No more chroot necessary.

Last edited by Mijzelf (2009-12-29 13:40:17)

@mijzelf, tried your suggestion  but it seems this code you suggested doesn't work, or at least it doesn't bring the funplug sshd and telnet in the air. (I already the tyope error e-data must be i-data as I have it on the hdd)
Luckily I did not put it in the actual rcS scipt but in a script called from rcS that is in a share i can access via samba so I can modify via samba server it without need to re-flash or even not having ssh connection.

Last edited by fvdw (2009-12-30 18:03:23)

think I know what the problem is, there is init file running prior to rcS that makes a new root fs and also chroots it.
Its in /dev/ram0 as far is
This init command file does not copy all folders in rootfs as it is in flash...
this is the content of the init file

#!/bin/sh


NEW_ROOT="/new_root"

# Prepare RAM disk for new root (${NEW_ROOT}/initrd)
/bin/mke2fs /dev/ram0
/bin/mount /dev/ram0 ${NEW_ROOT}
/bin/mkdir ${NEW_ROOT}/initrd

# Copy all necessary directories and files to ${NEW_ROOT} (/dev/ram0)
/bin/cp -a .mtoolsrc ${NEW_ROOT}
/bin/cp -a bin ${NEW_ROOT}
/bin/cp -a dev ${NEW_ROOT}
/bin/cp -a e-data ${NEW_ROOT}
/bin/cp -a i-data ${NEW_ROOT}
/bin/cp -a etc ${NEW_ROOT}
/bin/cp -a lib ${NEW_ROOT}
/bin/cp -a linuxrc ${NEW_ROOT}
/bin/cp -a mnt ${NEW_ROOT}
/bin/cp -a proc ${NEW_ROOT}
/bin/cp -a ram_bin ${NEW_ROOT}
/bin/cp -a root ${NEW_ROOT}
/bin/cp -a sbin ${NEW_ROOT}
/bin/cp -a sys ${NEW_ROOT}
/bin/cp -a tmp ${NEW_ROOT}
/bin/cp -a tmp.tar.gz ${NEW_ROOT}
/bin/cp -a usr ${NEW_ROOT}
/bin/cp -a var ${NEW_ROOT}
/bin/cp -a home ${NEW_ROOT}

# Need the following tools which are oringinally in /sbin
/bin/ln -s busybox ${NEW_ROOT}/bin/exec
/bin/ln -s busybox ${NEW_ROOT}/bin/chroot
/bin/ln -s busybox ${NEW_ROOT}/bin/init

# Pivot root
cd ${NEW_ROOT}
/bin/busybox pivot_root . initrd

# Change init from /dev/mtdblock1 to /dev/ram0
cd /
exec chroot . /bin/init
# NOTE: Don't add any code after 'exec' because script ends at 'exec'.

need to study this but it means it should be possible to write to this new root..

this is firmware 3.22.
I did not notice it but it is a normal linux sequence first running init and then the rcS script. Because of the chrooting the real rootfs is difficult to find. Also the new root is remounted in rcS at a certain point as read only. That can be changed easily by remounting it again but now as rw in my script that runs after rcS.  I already tried the code you suggested,  indeed you can make a /ffp directory but for whatever reason the mout --bind fails.  Can be the fact that md0 is a sym link be the problem although I tried also with the disk number but also it fails

ps should the e-data not be i-data ? (ffp is on hdd in my case on md0)

no I didn't had shell access as ffp rc script did not run, but in the mean time some progress.

I used this script

/bin/mount -o remount,rw /
/bin/mkdir /ffp
HARDDISKS=`ls -w 1024 /i-data`
for disk in ${HARDDISKS} 
do
    echo probe ${disk}
    if [ -e /i-data/${disk}/ffproot ]; then
        if [ -x /i-data/${disk}/ffproot/after_booting.sh ]; then
                        mount --bind /i-data/${disk}/ffproot/ffp /ffp 
                        /ffp/etc/rc
        fi
    fi
done

its a modified copy from the after_booting.sh script. This mounted it, strange that this works and a line with md0 in it not.
I used some command lines in other parts of my script with md0 in it to make sym links and copy files and those works.
ssh and telnet are running so ffp fired up ok. At least they are listening on the assigned ports.
However the box did not let me access the it via ssh as now uses the passwd and shadow file from zyxel.
There the user root is disabled and the user user unknown.
Had to find a way to change the default shadow file from zyxel to add a user and a password.
After some trials got a temporary fix to ad a a user and a password to those files and now I can access it via ssh (ffp)

The mount command now gives this output

/ $ mount
/proc on /proc type proc (rw)
/proc/bus/usb on /proc/bus/usb type usbfs (rw)
/sys on /sys type sysfs (rw)
/dev/ram3 on /tmp type ext2 (rw)
/tmp/var on /var type none (rw,bind)
/tmp/etc on /etc type none (rw,bind)
/tmp/home on /home type none (rw,bind)
/tmp/e-data on /e-data type none (rw,bind)
/tmp/i-data on /i-data type none (rw,bind)
/tmp/mnt on /mnt type none (rw,bind)
/tmp/dev on /dev type none (rw,bind)
/dev/sda1 on /ram_bin type ext3 (ro)
/ram_bin/usr on /usr type none (rw,bind)
/ram_bin/sbin on /sbin type none (rw,bind)
/usr/lib/security on /lib/security type none (rw,bind)
/usr/lib/modules on /lib/modules type none (rw,bind)
/tmp/usr_etc on /usr/local/etc type none (rw,bind)
/tmp/usr_var on /usr/local/var type none (rw,bind)
/tmp/dmsf on /usr/local/dmsf type none (rw,bind)
/dev/mtdblock2 on /etc/zyxel type jffs2 (rw)
/dev/md0 on /i-data/734b6479 type reiserfs (rw,usrquota)
/dev/md1 on /i-data/8d886087 type reiserfs (rw,usrquota)
/i-data/734b6479/.zyxel/zy-pkgs on /usr/local/zy-pkgs type none (rw,bind)
/usr/local/zy-pkgs/config on /etc/zyxel/zy-pkgs type none (rw,bind)
/usr/local/zy-pkgs/gui on /usr/local/apache/htdocs/pkg type none (rw,bind)
/i-data/734b6479/ffproot/ffp on /ffp type none (rw,bind)
/i-data/734b6479/ffproot/ffp on /ffp type none (rw,bind)
/ $

why ffp is two times mounted is still a question mark

almost there

Last edited by fvdw (2009-12-31 13:35:50)

yes of course now you mention it, it execute the script twice as it finds as well in 734b6479 and md0 a ffproot folder.
mmm..still need to try it once more without the do loop.

In the meantime I have used another ssh server to make access possible, dropbear.
I used binaries as I compiled for my spd8020 that contains also an arm9 processor. Its a more simply server but it fullfills my needs.
I only had to make 3 sym links to make it work including scp. Now I finally can see the real root fs in use and play around.

The problem with adding passwords to the shadow file I temporarily solved by using a sed command to replace the sentence containing the root password in that file (I used the info in /ffp/etc/shadow file). Still need to write a script that sets a password although this workaround works ok. seems the passwd command in this linux version has not all options
Any advice for that would be welcome.