Breaking into the Emprex NAS-100 firmware

[Bruce M Simpson]

Hi,

I just had a chance to look at this. So, Emprex are shipping a box (the 
NAS100) in violation of the GPL w/o releasing all relevant source code.

After I contacted Cavium about the GPL issues with their acquisition of 
Star Semiconductor, they sent me links to the binaries which Linksys 
were required to release for the WAP4400N.

I downloaded the WAP4400N materials and cross-compiled mtd-utils using 
Star's provided toolchain binaries (Gentoo crossdev is often broken for 
me). I then used mtd_debug to extract an image of the mtd0 partition, 
using a USB2 flash disk for data exchange.

I quickly noticed that the ARMboot image targetted for the WAP4400N, 
built from Linksys provided sources, doesn't match the ARMboot image 
inside the NAS100.

As far as I can tell this is down to two things:

 1. The environment region for ARMboot is inside ARMboot's flash 
partition, at the very end (0x1E000 to 0x20000, 4096 bytes including the 
4-byte CRC32 at the start of the region).

[The image for the WAP4400N assumes it's at 0x20000 and is 8192 bytes 
long.. so don't use that image.]

 2. The PHY drivers are slightly different.

So I looked at the STR9100 board support, and after noting the binary 
differences in the flash layout, skimmed some of the code to do with 
environment variable processing.

On a whim, I decided to deliberately corrupt the contents of the 
environment in the flash by modifying it with a hex editor and rewriting 
it w/mtd_debug, and rebooted. There is a CRC-32 at the start and it 
wasn't 100% clear which region was being used for it.

Having done this, I noticed that ARMboot drops into its prompt (after 
attempting to execute its 'firstboot' routine and hitting CTRL-C).  I 
was able to run Emprex's shipped kernel using "go 0x10020000", which 
seems to point to them not using the U-Boot image facility in ARMboot.

The majority of Star's patches to ARMboot are to add support for some of 
the onboard peripherals (Ethernet MAC, timers, UART etc).

BY THE WAY...

There is a funny bug in ARMboot which I've seen on little endian ARM 
such as these, and that is, you need to configure an alias of the 
*reverse* of the IP address of the default gateway in order for it to 
boot from the network successfully.

It seems to need a default gateway in order to use its bootp code, even 
when the server is on a directly attached network. Simply flipping the 
octets in the BOOTP/DHCP option given out to the box doesn't work, an 
actual alias on the gateway is needed.  As far as I know this bug hasn't 
been fixed.

So I guess now the way ahead is lit for folk to get U-Boot or similar 
onto this platform, as well as hopefully porting FreeBSD in future.

If anyone is interested in following this up please contact me, I might 
not have free time to look at this in any detail.

thanks
BMS