Contents

  1. Description
  2. Hardware
    1. v1
    2. v2
    3. v3
    4. v4
    5. v5
    6. v6
  3. Software
  4. Serial Console
  5. Hacking
  6. Telnet Console
    1. Unlocking the Telnet Cosole
      1. On Windows
      2. On Un*x
  7. Sources of IDT devboard
  8. Boot up log for v5

Description

NETGEAR WGR614 54Mbps Wireless Router

http://www.netgear.com/upload/product/wgr614/enus_right-lores_product_wgr614v5.jpg

Hardware

v1

Beginning the investigation into WGR614v1 hardware...

Here is a Korean page that likely has some info. The pictures closer to the bottom of the page that show the heatsinks removed are most telling. The 14-pin JTAG connector labeled JP1 is partially obscured by the antenna clip next to the reset button. The 12-pin serial connector from later hardware is nowhere to be found, but there is a 4-pin connector labeled JP2 that may or may not be serial. The netgear.cfg file this unit saves contains nothing human-readable. The MSP2007 chip pictured on the Korean page is now talked about on this wiki page. Google translation of the Korean page seems to indicate that the unit has 1MB flash and 4MB RAM.

The firmware images Netgear distributes for use with the upgrade function from the browser-based interface replace the entire contents of the 1MB flash chip, but they are compressed. To convert such an image to a raw form suitable for JTAG, use the following code, as "./a.out < inputfile.img > outputfile.bin" once compiled. 

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#define stringify(x) #x
#define tryme(x) if ((x)<0) { perror(stringify(__LINE__)); exit(1); }
int main(void){
        tryme(lseek(0,512,SEEK_SET));
        while(1){
                unsigned char buf[65536];
                off_t off;
                size_t len;
                ssize_t num;
                tryme(num=read(0,buf,6));
                if (!num) return 0;//no, processing did NOT fail; this means a SUCCESSFUL operation
                errno=EINVAL;
                tryme((num==6)-1);
                off=(buf[0]<<24)|(buf[1]<<16)|(buf[2]<<8)|(buf[3]);
                len=(buf[4]<<8)|(buf[5]);
                tryme(num=read(0,buf,len));
                errno=EINVAL;
                tryme((num==len)-1);
                tryme(lseek(1,off,SEEK_SET));
                tryme(write(1,buf,len));
        }
}
/*
Some programming novice saw the above (which works correctly out-of-the-box), and not only thought
the following code was better, but also thought that it could somehow work correctly. S/he should
learn how to read bad code better...

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[]){
        int fdi = open(argv[1], O_RDONLY);
        int fdo = open(argv[2], O_WRONLY | O_EXCL | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH);
        lseek(fdi,512,SEEK_SET);
        while(1){
                unsigned char buf[65536];
                off_t off;//unsigned long
                size_t len;//unsigned int
                ssize_t num;//signed int
                num=read(fdi,buf,6);
                if (!num) return 0;//einlesen fehlgeschlagen
                (num==6)-1;
                off=(buf[0]<<24)|(buf[1]<<16)|(buf[2]<<8)|(buf[3]);
                len=(buf[4]<<8)|(buf[5]);
                num=read(fdi,buf,len);
                (num==len)-1;
                lseek(fdo,off,SEEK_SET);
                write(fdo,buf,len);
        }
}*/

Stay tuned for more...

v2

Confirmed that the serial interface works on the WGT 624 v2 unit as described below, using inverters in RS232 TX and RX data lines. Superusername and password were not changed. These are also visible in the netgear.cfg back-up file that can be made from the http interface. Apply a long word (4 bytes) byte swap to change Little/Big-endian and make this readable on a x86 machine. The config file 'apcfg', accessible via FTP, can be edited when one makes sure that Byte count and Checksum at the end are corrected. Byte count applies to the bytes up to and including the period before 'Bytes'. Checksum applies to the bytes up to and including the period just before 'checksum'. I used 'Hex workshop' that provides the counts. In wla directory the ftp routine can be invoked to load up and down the various files. Had hoped to be able to activate Telnet by changing the Disable into Enable, but no change noted. Also tried Timeout from 0 to 180, and that has an effect on e.g. the serial connection going to sleep after 3 minutes. Not being a VxWorks expert I have not figured out yeat how to get telnet to respond from port 23. Further suggestions appreciated!

v3

Pic of circuit board in high res http://www.linux-hacker.net/misc/wgr614v3.jpg
Other hardware info http://www.linux-hacker.net/cgi-bin/UltraBoard/UltraBoard.pl?Action=ShowBoard&Board=RG

Seems to run from 10V to 20V input at about 3W draw. Internal 3.5V power drops off at < 5V input, wireless won't come up till 10V is applied for some reason. Solar power or car battery operation is possible with this box.

v4

is based on a Marvell Semiconductors 88W8510 802.11g baseband chip (with an ARM9 core) and an 88E6060 fast ethernet MAC/switch.

v5

v6

Software

Netgear GPL: http://kbserver.netgear.com/kb_web_files/open_src.asp
WGR614 downloads: http://kbserver.netgear.com/products/WGR614.asp

Serial Console

Confirmed that this is correct for the internal serial port (on a v3 box, go look at pic) (also confirmed for a v2 & v5 box).

Username / default password is not known! I tried all the typical, "netgear", "netman", "admin", "console", "root", "system", and so on.

Please call 1-888-NETGEAR and bug them till they give us the default username and password for the serial debug console!

The serial console is available on (the row of 12 pins to the right side in the picture). The pinout is as follows: 

   1     3.5V
   2     3.5V
   3     Data In   [from RS232 -> CPU] (3V logic levels)
   4     N/C
   5     N/C
   6     N/C
   7     N/C
   8     N/C
   9     Data Out  [from CPU -> RS232]
  10     N/C
  11     Gnd
  12     Gnd

I used a 74HC14 chip, VCC and GND were connected to use the 3.5V. I dangerously connected the TX and RX pins from my laptop directly to the in/out of two inverters on the chip and it worked! Most laptops can handle 5v like levels on the RS-232 pins (no -V needed GND is good enough), I used minicom (laptop with Linux) set to 9600 8N1 and no hardware handshaking. I didn't care at 3V on a 35 cent chip and it just works. Remember that there are some protections on the RS-232 port and resistors for protection plus the current we are talking about here is very low and well within RS232 spec and the chip would probably be first to go anyway and it's inputs are probably diode protected, it's been running now for more than 3 hours. I don't know why I have to explain myself here, don't you people try stuff anymore or does it have to be perfect and store bought? So put a resistor (10K ?) and/or a clamping diode (for -V) on the TX side into the HC14 chip if you are so worried, but don't go pay for some converter board unless you are really stupid.

I will post the startup text that comes out at boot soon.

The console settings are 9600, 8N1. Username is "Gearguy" and password is "Geardog". Once in, you will have a logon. Type 'windsh' to get a regular VxWorks shell.

Hacking

What looks like a jtag port is the 14 pin connector near the WAN port.

The following are notes from the WG602 page and may apply:

may apply, may apply, it's just info that may apply, the word is MAY

The BSDL of IDT can help us to have JTAG access on this box.

There's telnet running, but I don't have a box. Is it the prism54.org driver running there with iwconfig tools?

The config file of a v5 can be read as plaintext, but there is a checksum that looks like it is somewhere in the first 40 bytes... anyone able to figure out what this checksum is calculated based on? (Maybe someone with a working serial connection can find this out). Without a good checksum the router won't load a hand-edited config file.

If we can edit the config file on the v5, perhaps we can change "clidebug" to 1 and get telnet access?

We need to have the booter...

The IDT devboard name xxx is distributed with sources, so we can probably use it to recompile the whole stuff...

Telnet Console

Some Netgear routers run a telnet daemon which can be accessed from any computer on its local subnet after unlocking it (see below). The following devices are currently known or assumed to support this:

Please add to this list, so people will know which are supported and which are not!

Unlocking the Telnet Cosole

On Windows

Netgear provides a developer tool for unlocking the console access from a Windows client. Windows NT and later versions are assumed to work, administrator privileges are required. This was successfully tested on Windows XP SP2.

Here's the process: 

telnetEnable.exe 192.168.1.1 000FB5A2BE26 Gearguy Geardog

Correct character case is important here. 

U12H02900>

On Un*x

Netgear uses free software to make their products, but has not provided information or free software tools to enable them to be used. One needs to either use the Windows binary-only program or reverse engineer its operation in order to discover what magic packets Netgears' tool sends to the router to enable the telnet interface.

Unfortunately, there is no ready to go tool for Un*x, - yet. However, thanks to yoshac_at_member_dot_fsf_dot_org the following could be determined on the data format and transforms performed by Netgears' telnetEnable.exe and a work is in progress to implement the entire tool as open source. See OpenWrt Wiki for C code to generate the enable packet, which can be sent to the Netgear using the (Linux) nc command.

A probe packet is built using the data supplied on the command line, and is then signed using the RCA MD5 hashing algorithm. After signing, the entire probe packet is encrypted using the Blowfish algorithm, using a private key.

The probe packet payload format is as follows: 

struct payload
{
char signature[0x10];
char mac[0x10];
char username[0x10];
char password[0x10];
char reserved[0x40];
}

The above payload format is transformed by the tool algorithms as follows:

The MD5 checksum is calculated for the contents of the probe payload MAC, username and password fields only, and is done using the normal 3 passes (MD5init, MD5update, MD5final) with the default RCA seed. The resulting 16 byte MD5 checksum/hash is then stored into the signature array of the probe payload.

The entire probe payload (including the reserved area, which is always null for this example) is then ENCRYPTED using the blowfish algorithm. The secret key used for the blowfish encyption is: AMBIT_TELNET_ENABLE but prior to encryption, a '+' followed by the password is appended to the secret key.

The encrypted probe packet is then sent to telnet port (23) on the router using raw TCP sockets in the standard manner. Curiously, the telnetenable.exe program also includes the necessary support to decode packets incoming from the router, but there does not appear to be any two-way handshake implemented, it is simple a raw TCP send from the client to the router.

Note: The encrypted probe packet is sized as char output_Buf[0x640] but only an encoded data length of size of 0x80 appears to be used by the code. It is unknown what other capabilities may be similarly enabled via the 'reserved' field, or by other passwords.

[ Source code for a 'C' re-implementation of these algorithms has been released by yoshac under the GPL, for use as the basis of a Un*x version of the tool currently in development. Instructions and download here: http://seattlewireless.net/telnetenable.c ]

Sources of IDT devboard

 lftp ftp2.idt.com
 user: apps
 pass: 29apps28
 cd /pub
 get linux.txt
 cat linux.txt
 cd LINUX
 get idt_linux_docs.tar.gz initrd.linux-2.4.18.tar.gz linux-2.4.18.tar.gz mipstools.tar.bz2 mipseltools.tar.bz2

Hmmm... This device is Broadcom BCM47xx based, not IDT.

Boot up log for v5

CFE ver 1.0.1(Top) Wed Jun 30 07:26:46 CST 2004
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 2004.4.28.0
Decompressing... \muxDevLoad failed for device entry 1!
muxDevLoad failed for device entry 2!
muxDevLoad failed for device entry 4!
Failed to attach to device Attaching interface lo0...done
BCM47xx VxWorks BSP - Jul 23 2004 14:08:58
Flash : MX29LV800B 1Mx8 TopB
pinglib init
configure vlans
configure vlans...done
0x807ffdf0 (): task deadCan't attach unknown device  (unit 0).
Enable wan port ok!
CC module initialized successfully

WAN Initialisation                                 [SUCCESS]

 PPTP Initialised
Firewall INIT completed
AD Init completed FW initalized
IGWIpRsmInit():  ....End
 vxBitsInit
add interface mirror0
DNS redirect INIT
in abRegisterInputHook inputPktHook: 80214788
add interface mirror0
add interface et0
add interface mirror0
add interface et0
BlockSides keywords WebAppControl add successfully

Syslog configuration successfully updated
Info: No FWPT default policies.
DHCPS: init dhcps: devname=mirror0
DHCPS:Set the default Lease Time to 86400
Set option ACOS_DHCP_OPT_ROUTER to 192.168.5.1:
Set option ACOS_DHCP_OPT_DNS_SERVER to 204.127.202.19:216.148.227.79:
Set option ACOS_DHCP_OPT_NNTP_SERVER to wan:
NAS task tNASlan started.
Login: add interface mirror0
add interface et0
add interface et0
add interface mirror0
add interface et0

Login: Gearguy
Password: *******
U12H02900> ?

Commands are:

bridge         ddns           exit           firewall       ip
lan            passwd         reboot         save           show
sntp           uptime         version        wan            web
wlan

 '..'    return to previous directory

U12H02900> version
Release version : Netgear Wireless Router WGR614v5
                  U12H02900/V1.0.3RC7/1.0.3
         Time   : Jul 23 2004, 14:09:03

CategoryAccessPointHardware

SeattleWireless: NetgearWGR614 (last edited 2008-04-13 23:34:51 by localhost)

Bandwidth Provided by speakeasy.net