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

Unfortunately no one can be told what fun_plug is - you have to see it for yourself.

You are not logged in.

#1 2009-12-19 23:31:14

fvdw
Member
Registered: 2009-12-19
Posts: 33

use own firmare

Hi everyone, I am new to this forum and acquired sometime ago the nsa220
A nice device but I don't like the firmware and especially the complicated way it is set up.
Also the user interface is painfully slow to open etc.

I have read some post here of Mijzelf and Sala (nice work by the way and thanks for sharing) who are apparently working to use  a custom firmware on this box. Unfortunate the guides are very clear to me. My experience with changing stuff in flash is not big but I have some work in upgraing firmware of LS-GL devices.
What I would like is that to simply boot from a partition on the HDD, there I can put my own kernel and other stuf and using a normal Linux structure on the disk.
Is there a simple way to come to this ? I mean to modify the bootloader in a way that it looks to a partition or even better a boot flag to boot from.

thks for any inputs

Offline

 

#2 2009-12-20 22:55:03

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

Theoretically it's not that hard to let the firmware boot from hd. ZyXEL offers the firmware sources for download (ftp://opensource.zyxel.com), and the cmdline specifying the bootpartition is defined in kernel .config, so you could just download the sources, change .config, build firmware, and flash it using the webinterface.
How hard it is in practice I don't know, I didn't try it. Sala reported that the kernelsources are not completely sufficient to build the actual firmware kernel, so maybe your self-compiled kernel won't work.

However, I've walked another path, and used Fonz' reloaded.ko kernelmodule to boot my own kernel, specifying the boot partition. Now I am running Debian Lenny on my box.
Pro of this concept is that I don't need to flash the firmware. It's all on an usb stick. And I can easily and safely test other kernels and distro's. And I didn't void my warranty. (Well, actually my box is too old for warranty)
Con is a longer boottime, because it always boots twice, and the usb stick needs always be attached (at least during boot).

I hope to share a working how-to with the community in a few days/weeks.

Last edited by Mijzelf (2009-12-20 22:56:17)

Offline

 

#3 2009-12-20 23:43:21

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

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.

Offline

 

#4 2009-12-21 13:07:53

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

fvdw wrote:

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.

Putting the firmware on harddisk has also it's cons. LaCie does it, and many people have problems with exchanging harddisks, or putting back a system to factory defaults, or ... For the cheap NASses LaCie doesn't support a disk exchange, so when the disk dies you can throw away your NAS. For the more expensive ones they sell 'preconfigured' harddisks (firmware preinstalled) for about twice the price of an empty disk.
Of course for a hacker this should not be a problem, but they are not the target of the NAS manufacturer.

I prefer my ZyXEL.

BTW, starting with fw 2.30 the NSA220 has a hybrid solution. The contents of /usr is put on harddisk. (It's originaly stored in a high compressed lzma file in flash). And in fw 3.22 you can download and install extra modules, which are installed on disk too.

Offline

 

#5 2009-12-21 22:21:18

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

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.

Offline

 

#6 2009-12-23 13:45:48

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

some ideas after studying the files on the NSA220
There is a command file in the directory sbin that seems to be used to write the firmware upgrade to flash it is this one
fwupgrade_erase_write_ras.sh

In there you find a line with a command where the firmware upgrade file is split in two binaries, kernel.bin and initrd.bin
Then these two are written to flash. Also the command to be used for that can be seen in the command file.
So my conclusion is that it must be possible to write a kernel (kernel.bin) and a rootfs (initrd.bin) to the flash from the command line. Now Sala already explained how to make a kernel.bin file, the only information missing is how to make an initrd.bin file

Further I found that /dev/mtdblock1 seems to contain the rootfs, just mount it and you can browse the content. Its a squashfs file system so readonly. I guess this is the content of initrd.bin after written to flash but I am not sure.
The idea is to use this as base (copy it to disk to make it writeable) make some adaptations, for instance modify the rCS script used during boot to let it install some basic stuff I like (no need anymore for a usb stick continuously inserted), make from this adapted rootfs a new initrd.bin file and write this to flash using the commands in the file mentioned. The only thing needed is how to make a valid bin file...

Last edited by fvdw (2009-12-23 13:47:24)

Offline

 

#7 2009-12-23 14:44:58

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

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.

Offline

 

#8 2009-12-23 15:28:31

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

thks mijzelf

here a link to the convopit computer forum, you need to register I believe to access it.


http://convopit.org/forum3/viewforum.php?f=120

Yes I also read your post about booting from the usb stick, in the meantime I found in the source files on the zyxel website the necessary scipts and info to make an initrd.bin file and merge that with the kernel.bin in a firmware file.

But I guess it is sufficient to have the individual ones as the firmware upgrade script will split it again in two.
So now I need to become brave enough to modify the rootfs and write that to flash.

about the boot time of the nsa220, think this extracting from flash of compressed files  is slowing it down considerably.

Last edited by fvdw (2009-12-23 15:38:08)

Offline

 

#9 2009-12-28 14:46:39

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

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)

Offline

 

#10 2009-12-28 18:46:11

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

succes,
I flashed a new rootfs using Putty and a command line script. I based that script on the original firmware upgrade script. With that I wrote my home made root file system binary to the flash.
After that I did some checks to see if it went ok, the box still responds via putty and ssh now, so before reboot better make some check and maybe make some corrections if still possible.
I mounting the freshly flashed root file system and that went ok, it appeared to be readable and it contained my modified rcS file. So I was confident enough and let it reboot and keep the fingers crossed.
After some minutes, man this thing takes its time to boot, it came up as usual and I could access it via ssh etc and furthermore it has executed my test script.
There was one thing the samba server was not running, FTP, media sever, telnet, ssh were ok. In the log it mentioned that nmdb has shut down because it found a pid that it was already running, maybe I forgot to shut down the smb server before reboot. I just will reboot it once more and see if it is still a problem.

yes..ready to go now to make my modifications and get rid of the usb stick in the front.

Offline

 

#11 2009-12-28 18:55:50

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

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

Offline

 

#12 2009-12-29 02:15:34

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

I have a question about the funplug

How is /ffp dir and its sub dirs coming into the root file system (/) ?
its seems that it has the same content as /i-data/md0/ffproot/ffp and if you change something in one the same change is visible in the other. So they are apparently one and the same. But I can not find in which script /ffp and  /i-data/md0/ffproot/ffp are linked ?

I can find that the fun plug root file system and content is unpack but all are done in  /i-data/md0/ffproot/
Also I see int funplug init script that several folders are linked between in ffproot with the same in root, but no link between /ffp with  /i-data/md0/ffproot/ffp.

Some tips would be appreciated

Last edited by fvdw (2009-12-29 02:20:11)

Offline

 

#13 2009-12-29 11:11:48

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

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

Offline

 

#14 2009-12-29 11:43:26

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

thanks mijzelf, yes I use your scripts but I want to move on and remove the usb stick in the front now that I have adapted the rcS file. But I want to understand how ffp works before doing that.

The usb_key_fun.sh fires up after_booting.sh, but studying the last command file I still can not find how /ffp comes into root directory and how it is linked to /i-data<<nr>/ffproot/ffp
PS. the dir's like /bin and  /i-data/<nr>/ffproot/bin  and others are linked in the after_booting.sh script but not /ffp . So how is that accomplished ?

Offline

 

#15 2009-12-29 13:38:08

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

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

Code:

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:

Code:

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)

Offline

 

#16 2009-12-29 15:02:09

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

ok think I got it

Offline

 

#17 2009-12-30 17:53:43

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

@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)

Offline

 

#18 2009-12-30 19:34:05

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

Too bad. I can't think of a reason why this shouldn't work, except, maybe, some /etc probems. The 'original ffp-script' has it's own /etc, while in your case the 'real' one is used.

You should be able to restore the old situation by changing your script:

Code:

# header and stuff

cd /i-data/md0/ffproot
/i-data/md0/ffproot/after_booting.sh /i-data/md0/ffproot

Offline

 

#19 2009-12-30 23:58:08

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

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

Code:

#!/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..

Offline

 

#20 2009-12-31 10:33:54

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

When this script is actually run, you have a writable root. So changing the code to:

Code:

mkdir /ffp
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

should make it run.

Which firmware is this?

Offline

 

#21 2009-12-31 11:23:14

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

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)

Offline

 

#22 2009-12-31 12:44:23

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

Yes, e-data should be i-data. The symlink should be no problem. Do you have shell access? Maybe you can find the reason for the failed 'mount --bind' in dmesg or /var/log/messages.
If not, you could try to redirect the stdout and stderr:

Code:

exec >>/i-data/md0/ffproot/ffp.log 2>&1
mount -o remount,rw /
mkdir /ffp
mount -o remount,ro /
# and the rest

I *think* you should remount the root ro again, after making /ffp. In my attempt to make the firmware rw, it turned out the firmware doesn't like a writable root.

Offline

 

#23 2009-12-31 13:33:10

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

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

Code:

/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)

Offline

 

#24 2010-01-01 10:18:02

Mijzelf
Member / Developer
Registered: 2008-07-05
Posts: 678

Re: use own firmare

fvdw wrote:

why ffp is two times mounted is still a question mark

Because it *is* mounted twice. Once via /i-data/734b6479, and once via /i-data/md0. You can add a line 'exit 0' after '/ffp/etc/rc'.

Offline

 

#25 2010-01-01 16:41:24

fvdw
Member
Registered: 2009-12-19
Posts: 33

Re: use own firmare

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.

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2010 PunBB