In December 2007 I was looking for a network attached storage (NAS) backup solution with the following properties:
- Raid 1 support
- Sata II
- Gigabit ethernet
- SMB support
- NFS support
- Linux OS on the NAS
So I did some research on the web and the Zyxel NSA-220 seemed to be the perfect candidate, especially due to the information I found about the NFS support of the device on the US Zyxel website. So I bought one together with two 500GB harddisks.
Well, to my surprise there was no NFS support at all available for the device and my questions to the German and US American Zyxel support did not give me the feeling, that NFS support was about to be introduced by a new firmware update. A device running a Linux OS and not supporting NFS but only SMB made me angry, so I decided to try to get my own operating system running on it.
First of all the good news: the source code to create a new firmware is available for download. That is: Zyxel was forced by the copyleft nature of GPL to make the source code available, but apart from that they don't seem to be very interested to give further support. So since the sourcecode is available and the NSA-220 offers the possibility to upload new firmware via http, you can build your own kernel and upload it that way.
But be warned:
- Nobody guarantees the new firmware to be runnable on the device, especially Zyxel does not. If it is not, you will brick your device, that is: it won't boot anymore and thus you will loose the possibility to upload new firmware via http!
- It was reported, that someone bricked his device by simply building the new firmware according to the Readme file that comes with the firmware sources and uploading it via http interface. The reason for that is, that the build process needs root permission. If you start it as a non-root-user, the call to mknod in one of the scripts doing the build process will fail and thus create a buggy firmware image. Uploading this image will perfectly sure brick your device. So be careful: I currently have no idea, if there are more pitfalls during the build process. I will upload more detailed information about the build process, as soon as I start to replace the firmware by my own build, but I regret to do so, before I have an alternative access to the device.
To have a fallback you need an alternative access to the device, e.g. via serial interface. The hope is, that this will offer a possibility to up-/download firmware in a more basic way. So, if the device won't boot anymore, you still can upload a new firmware (e.g. the original firmware or your next compilation try) by connecting the NSA-220 via serial interface to another computer. As you surely noticed, there is no serial port to connect a serial cable to on the outside of the NSA-220, so the first thing to do is to find a serial port connector on the device's mainboard.
To locate the serial port connector, I took some photographs of the mainboard and tried to analyze it.
Mathuin here with an update on the serial port.
I emailed customer support because I wasn't as smart as the above contributor in that I tried to build and install the firmware. The firmware must be built as root or the mknod calls fail which means there's no useful /dev tree which means you'll brick your device if you're not careful. I was ... not careful. Anyway, I asked support whether that was indeed the serial port and they said that serial port was for factory use only. The second photo above shows a five-pin header with the fourth pin removed. The top pin had voltage, the middle pin oscillated as if it was TxD, the bottom pin I think is RxD, and the last pin is ground. My oscilloscope is acting up so I don't have any real useful information, but it did seem as if the serial port was at 115200 due to the approximate length of the bits. Good luck!
Mathuin, 2008 Mar 18
I connected the serial pins to a USB-to-serial adapter, set up Tera Term Pro for 115200 8N1, and started it up. The device spit out roughly 50k of binary spoo. I saved it to a file and will attach it to the wiki once I figure out how. I tried every other baud rate down to 9600 with 8N1 and 7E1 and no combination returned clean text. Work has a nicer oscilloscope which may be able to automatically decode the data that comes across. Stay tuned!
Mathuin, 2008 Mar 23
I posted a message to you to clarify some details.
Nonalignmentpact 17:17, 28 March 2008 (CDT)
I replied to your message, Nonalignmentpact, but I'll include the relevant information here for others:
The pin with voltage appears to have 3.3v as does the transmit data, so I'm going to wire up a small circuit using a [[Max3232]] chip to translate it to "normal" RS232 voltage levels. It's my hope that this will allow me to actually decode the values coming across the serial line. Looks like a trip to Fry's is in order!
Mathuin, 2008 Apr 02 --
Well, good news: Today (09.04.2008) I saw my Zyxel-NSA-220 booting via a serial line!
The details: The pin assignment is:
- 1 voltage
- 2 TxD
- 3 RxD
- 4 empty
- 5 ground
(assuming 1 denotes the upper pin on the above detailed photo). You need an adapter with a Max3232 chip to translate the 3.3V serial port on the Zyxel mainboard to a 12V standard serial port of a desktop computer. You only need to connect the lines TxD, RxD and ground to the corresponding pins on the Max3232 (that is: leave out the voltage pin, you don't need it)
Then you can use the minicom program on the desktop computer to see data on the serial line. Setup minicom to use your serial port (e.g. /dev/ttyS0), baudrate 115200 and parity bits 8N1. Then startup the NSA-220 and see the boot log messages fly by.
Now we have access via a command shell, it might be a good idea to collect some hardware info about the device. I put this information to an own page.
Next step is to find out about possible commands to be used to read and write the firmware of the Zyxel device.
If you start the NSA-220 with a serial line connected to it you will first see the "bios" of the device showing some info:
Bootbase V20061226 | 12/26/2006 10:58:17 DRAM0 Size: 128 MB DRAM POST: Testing: 130976K...OK
DRAM0 Test SUCCESS !
System Memory Mapping RAM0: 0x00000000~0x07FFFFFF (128 MB) Bootbase: 0x00000000~0x00006547 Stack: 0x00006548~0x00018D47
Found 28F128J3 at address 0xF8000000 Boot-up Bootext...
Bootext V3.1 | 07/16/2007 15:55:52 Flash Detect.... Found Intel 28F128J3 flash at memory address 0xf8000000
System Memory Mapping Flash0: Intel 28F128J3 at 0xF8000000 (16MB; Block0~Block127) RAM0: 0x00000000~0x07ffffff (128MB) Bootloader: 0x00020000~0x0004577f Stack: 0x00045780~0x0005d27f Flash Temp Buffer: 0x07fe0000~0x07ffffff (128KB) vendername = ZyXEL Communications Corp. productname = ZyXEL NSA220 featurebit   = D1 01 MAC = 00 19 CB 3E 4B 3A CountryCode = FF EngDebugFlag = 01
Hit ESC key to stop boot-up kernel...
When reaching the last line you have some seconds left to press the escape key to prevent the Linux kernel from being booted. You will then find yourself in a bootbase shell allowing some simple commands. Typing
will show you the available command set. Here it is:
AT just answer OK ATCR Clear screen ATHE print help ATBAx change baudrate. 1:38.4k, 2:19.2k, 3:9.6k 4:57.6k 5:115.2k ATCMx,y,z compare memory contens from address x and y, length z ATCPx,y,z copy memory contens from address x to y for length z ATDUx,y dump memory contents from address x for length y ATWBx,y write address x with 8-bit value y ATWWx,y write address x with 16-bit value y ATWLx,y write address x with 32-bit value y ATRBx display the 8-bit value of address x ATRWx display the 16-bit value of address x ATRLx display the 32-bit value of address x ATAG init kernel parameters ATGO(x) run program at addr x or boot router ATGT run Hardware Test Program ATRTw,x,y(,z) RAM test level w, from address x to y (z iterations) ATICx,y(,z) x = I2C address, y = register offset, z = write value ATUBx xmodem upload bootbase ATUR upload router firmware to flash ROM ATDOx,y download from address x for length y to PC via XMODEM ATUPx,y upload to RAM address x for length y from PC via XMODEM ATXSx xmodem select: x=0: CRC mode(default); x=1: checksum mode ATBTx block0 write enable (1=enable, other=disable) ATERx,y erase flash rom from block x to y ATWFx,y,z copy data from ram addr x to flash addr y, length z ATRFx,y,z copy data from flash addr x to ram addr y, length z ATFKop,x,y Flash lock operation 0:Unlock/1:Lock/2:Lock status; block number from x to y ATWMx set MAC address in working buffer ATIP[x][,y][,z] Setup IP address; x is Server/Remote IP, y is Host/Local IP, z is netmask ATTCx,y upload file y from TFTP server to RAM address x (length of filename<=20) ATTSx upload to RAM address x from TFTP Client ATBPx BootP with TFTP download image ATENx,(y) set BootExtension Debug Flag (y=password) ATSE show the seed of password generator ATWZa(,b,c,d) write ZyXEL MAC addr, Country code, EngDbgFlag, FeatureBit to flash ROM ATCB copy from FLASH ROM to working buffer ATCL clear working buffer ATSB save working buffer to FLASH ROM ATBU dump manufacturer related data in working buffer ATCOx set country code in working buffer ATFLx set EngDebugFlag in working buffer ATSTx set ROMRAS address in working buffer ATSYx set system type in working buffer ATVDx set vendor name in working buffer ATPNx set product name in working buffer ATFEx,y,... set feature bits in working buffer ATMP check & dump memMapTab ATSR system reboot ATTTx,y(,z) Test timer functions. x as interval, y as time unit (m, u), z as repeated times ATLK(x,y) Load kernel x to memory addr y, and go ATLI(x,y) Load Initrd x to memory addr y, and go ATKI(1,2,3,4) 1=kernel name, 2= initrd name, 3= kernel addr, 4=initrd addr ATKF(x,y) Load kernel x to memory addr y, and nfs root file system ATNF(x,y,z) x:nfs server ip y:rootpath, z:local ip
Note, that some of the commands seem to use parentheses, others do not. In all commands I tried up to now the parentheses had to be omitted.
In my opinion the most promising commands found here are
ATIP[x][,y][,z] to adjust the network parameters ATBPx to boot via bootp protocol ATTCx,y to download a kernel via trivial ftp ATKF(x,y) Load kernel x to memory addr y, and nfs root file system ATNF(x,y,z) x:nfs server ip y:rootpath, z:local ip
So let's go set up an atftp server and then try to boot via an image downloaded via tftp.
I confess, first I did not manage to make ATBP or ATTC work properly. First I thought that it was my fault and that I didn't use the right parameters for the commands or the like. To help you avoid wasting lifetime, please note the following two facts:
- Some of the networking commands (e.g.: ATTC) tend to fail with messages like "Can not establish TFTP connection! error code=2" or the like, sometimes they also report that they didn't manage to initialize the ethernet card properly. In that case it helps to simply unplug the ethernet cable at the device and then to plug it in again. In my case this always helped and the commands did no longer fail
- The ATBPx command is expecting a memory address as parameter x, after you enter the command, there will be a message telling you the MAC-address used and afterwards you have to press <enter> once again!
Up to now I couldn't find a valid set of commands to boot the NSA-220 via network, but I will keep trying.
To be continued...
Hi, I was about to return my NSA220 when I could not find any information on how to hack it but after looking at your efforts, I have decided otherwise. Pleas take a look at this website as it may help you figure out how to hack this box. This NAS device also uses the Marvell processor and has similar specifications. http://www.openprotium.org/tiki-index.php?page_ref_id=35
I collected a lot of informations about Zyxel hardware, you can find all here
It would certainly help,