Notice: Some of the information below might help you use another VOIP provider, but that doesn't mean that you are legally entitled to. The License Agreement between you, the product owner, and Vonage may legally prevent you from using this device with another provider. Additionally, the following information is provided as is. Certain actions, such as loading new firmware can turn your expensive home router into a useless brick if not done properly. Use of the following information is at your own risk: First, this all started when I tried to use my router and found its performance sucked more than a 'Hoover'. After looking into upgraded firmware (and not getting anywhere), it found that setting the MTU on the router to a lower number was all I need do (and yes, if pays to RTFM: the manual clearly states that the default is 1500 but that they recommend a lower number). So, happy router, happy user... or so it would seem. When the web admin interface failed to load in a timely manner (due to the MTU settings), I tried both telnet and SSH. I did find that SSH is open on the router by default, but I wasn't allowed in... if I'm not then who is??? So I started to look around: SSH Attempts: 1. download and setup a syslog program (such as kiwisyslog.com) 2. login to the web interface to your router and go to admin\log 3. set all logs to go to the IP of the machine running syslog (static is best) 4. attempt to SSH into your router... 5. hit head repeatedly when you can't figure out user/password 6. Notice that "Admin" is accepted as a user 7. Still hit head repeatedly when you can't figure out the password 8. Take a nap, come back later and try a different approach. NOTE: You can also view some of the previous log entries by visiting: http://192.168.15.1/cgi-bin/webcm?getpage=../html/status/syslog.html (after you have logged in) Interesting Web Interface Findings: First thing to notice is that every page (after you have logged in) is actually retrieved by 'webcm': http://192.168.15.1/cgi-bin/webcm?getpage=../html/status/syslog.html What is "webcm?" It is the gatekeeper. It is guarding all the doors. It is holding all the keys, which means that sooner or later, someone is going to have to fight it. Let's break down the above url: http://192.168.15.1 -- your router IP /cgi-bin/ -- path to gatekeeper webcm? --the gatekeeper getpage= --the procedure ../html/status/syslog.html -- the requested page So, the first thing that I noticed is the "../html/" I tried http://192.168.15.1/html/ and was greeted with the standard logon page... This really didn't shock me as it simply presented me with an index page. Next I tried http://192.168.15.1/html/status/ and was presented with a nice directory listing of all the files in status. Being able to see the file is half the battle. If you try and open any of the files you will notice that they show garbage or rather they aren't interpreted. So, any page you want to see must be passed to the 'gatekeeper' (as was done in the above 'syslog.html' URL) With this knowledge I logged in normally to the router and found all the possible html/ directories that I could. Here is a list of the directories (no doubt I've missed some): http://192.168.15.1/html/adv/ http://192.168.15.1/html/admin/ http://192.168.15.1/html/voice/ *-good stuff http://192.168.15.1/html/status/ http://192.168.15.1/html/security/ http://192.168.15.1/html/wireless http://192.168.15.1/html/tools/ And now for the meat .... Here are some of the more interesting pages, including those used to dealing with the SIP settings of the router. Some of them (the voice settings) will try to kick you out by using JS... simply press ESC a few (dozen) times when the page is done loading to prevent your browser from sending you away (this is one case where I found IE to be better as it was slower to try and send me away). http://192.168.15.1/cgi-bin/webcm?getpage=../html/adv/sysinfo.html http://192.168.15.1/cgi-bin/webcm?getpage=../SetupWizard.htm http://192.168.15.1/cgi-bin/webcm?getpage=../html/tools/update_result.html http://192.168.15.1/cgi-bin/webcm?getpage=../html/voice/Provision.html http://192.168.15.1/cgi-bin/webcm?getpage=../html/voice/voiceSip.html And to do another take on the movie: webcm is not the only hope, there is another: http://192.168.15.1/cgi-bin/webcm?getpage=../../ should list not only 'webcm', but 'firmwarecfg' as well. You can view this binary by visiting: http://192.168.15.1/cgi-bin/webcm?getpage=../../firmwarecfg of course you van view the 'gatekeeper' himself by visiting: http://192.168.15.1/cgi-bin/webcm?getpage=../../webcm Back to my firmware issue. I never could update my firmware as the 'user/tivonpw' account was 'not allowed this level of access' or something like that. I did find a page that seemed to deal with flashing the firmware, but didn't seem to work for me: http://192.168.15.1/html/tools/update_result.html and thus: http://192.168.15.1/cgi-bin/webcm?getpage=../html/tools/update_result.html Anyway, I hope these findings are a step in the right direction to actually allowing open firmware to be loaded on this brick. BTW My brick's firmware is version 1.00.18.
to get to flashing utility page go to html://192.168.15.1/update.html It will ask you to log in but your regular login will not work. The username is Admin (with the capital A) and the password that vonage gave me is (Case Sensitive) f197mrwW03 Hope this helps if not call Vonage and tell them you want to update your firmware and they may help you out. PEACE
More info available First, thank you to anon. With the new 1.00.37 firmware, I tried the password you provided with no luck. I can't help but wonder if your password is possibly derived from some serial number on your box... clearly not the device itself, but possibly the board or one of the chips... this type information was available at: http://192.168.15.1/cgi-bin/webcm?getpage=../html/adv/sysinfo.html on my old firmware, but unfortunately it was removed from the new version. As stated above, I managed to update the firmware to the newer 1.00.37 revision. I'm currently away from any wired internet, so updating the firmware without admin passwords was a bit difficult(the tivonpw account was locked or something like that). In short, I used XP to bridge by wireless and ethernet port. As I didn't have a crossover cable, I plugged into a normal lan port and then ran a connection from the wan port back to the one of the lan ports. Not pretty, but spanning tree seemed to figure out what was going on. As my laptop was the middle man for the router (talk about backwards), I was able to use ethereal to monitor the update procedures. The update process is really quite elegant. Ignoring all normal network discovery packets, here is the run down: Update Process: 0. Power cycle 1. Resolve tftp.vonage.com using the DNS settings provided 2. Request an XML configuration file from the tftp server -- Although the file ends with XML it is actually binary data, more below 3. Resolve time.vonage.com (getting hostname from XML data?) 4. Perform NTP time sync with time.vonage.com 5. Resolve ti.tftp.vonage.com (no clue why) 6. Resolve tftp.vonage.com (no resolve cache at this point?) 7. Request the IMG update (as listed in the XML file?) from the tftp server 8. Apply image? 9. Repeat 1-4, but fail on new XML request as there are no updates The 'xml' file is infact some type of binary file. I assumed it was compressed using 7z or the like since the GPL files provided from linksys do include 7zip. No matter what extention I would set the 'xml' file to, it still wouldnt' open. Additional Findings The new firmware provdes the ability to back up the configuration. I assume that doing this probably backs up all kinds of information about the router (passwords, etc) so I thought maybe downloading, editing and uploading this file might provide a nice backdoor. Alas this file, a ".bin" file, is also some type of binary file. I couldn't determine was encoding or compression was used, but the first 4 byes are "LMMC", and again google couldn't find any file types that started with "LMMC." Aside from some of the pages that I've mentioned in my previous post, you can also visit ftp://ftp.linksys.com/datasheet/WRTP54G_ds_RevA.pdf and see some of the standard SIP protocols that are indeed used in this ATA. nmap results (fake mac, wan ssh/web, no wrls, and .1=LAN, .2=WAN) > nmap -v -v -sV -O -p 1-10000 192.168.15.1 192.168.15.2 Initiating SYN Stealth Scan against 2 hosts [10000 ports/host] at 22:52 Discovered open port 80/tcp on 192.168.15.1 Discovered open port 22/tcp on 192.168.15.1 Discovered open port 22/tcp on 192.168.15.2 Completed SYN Stealth Scan against 192.168.15.1 in 5.23s (1 host left) Discovered open port 10000/tcp on 192.168.15.2 The SYN Stealth Scan took 74.15s to scan 20000 total ports. Initiating service scan against 4 services on 2 hosts at 22:53 The service scan took 5.02s to scan 4 services on 2 hosts. For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled Host 192.168.15.1 appears to be up ... good. Interesting ports on 192.168.15.1: (The 9998 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 22/tcp open ssh? 80/tcp open http? MAC Address: 00:00:00:00:00:00 (Unknown) (Real MAC removed) Device type: general purpose Running: Linux 2.4.X OS details: Linux 2.4.6 - 2.4.21 --Fingerprint removed-- Warning: OS detection will be MUCH less reliable because we did not find at lea st 1 open and 1 closed TCP port For OSScan assuming port 22 is open, 39019 is closed, and neither are firewalled Host 192.168.15.2 appears to be up ... good. Interesting ports on 192.168.15.2: (The 9998 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE VERSION 22/tcp open ssh? 10000/tcp open snet-sensor-mgmt? MAC Address: 00:00:00:00:00:00 (Unknown) (Real MAC removed) Device type: general purpose|media device|broadband router Running: Linux 2.4.X|2.6.X, Pace embedded, Panasonic embedded OS details: Linux 2.4.21 (Suse, X86), Linux 2.4.6 - 2.4.21, Linux 2.6.8 (Debian) , Pace digital cable TV receiver, Panasonic IP Technology Broadband Networking G ateway, KX-HGW200 --Fingerprint removed-- WTF does this nmap stuff mean? - I asked for SSH to be open on lan/wan and it was. - I asked for http to be open on lan/wan, both are open, but only lan shows up. - I asked that port 8080 be used for remote http admin, it isn't. - Port 10000 is open, telnet in and get a blinking cursor, not sure why. Closing Anything new that I come across will find its way here. By all means, share what you know if you've got any info. I'd love to determine the ssh password, but still no luck. Maybe if the factory loaded firmware for the WRT54G supports SSH then someone in the linksysinfo.org community knows the SSH password for their model; maybe they are the same?
Re: More info available Good work rvf3! The type of compression used is lzma ... but it seems to be a custom lzma specific to the squashfs1.0 that's used specifically to compress these bin files. If you download the linksys gpl source you'll see what i'm talking about. I've tried patching my home kernel with the latest squashfs (2.2) and the latest lzma compression patch ... which should allow me to take the vonage image and mount it using mount -o loop ... that is after using dd to output the image starting at the hsqs beginning of the lzma compression. Didn't work, doesn't like the latest squashfs2.2. I somehow have to figure out how to use the squashfs1.0 and lzma provided in the linksys source packages to work with my kernel so I can mount he vonage images. I think this is the way to go as far as accessing the firmware image and figuring out what type of security vonage used, and what the default password is. let me know what additional info you have. Y
This is my experiment.... dl the 1.00.37 firmware howto mount the filesystem? sol: dd if=xxx.img of=fs.img bs=1K skip=576 mount -o loop fs.img /mnt/loop I find the /etc/passwd is the sym. link in /var/tmp/passwd. But, it was not included in var.tar. So, I think that the passwd is downloading from server....
I'm suspecting your distro has the required FS compiled/modular or an autodetect on the FS type. Attempting with your directions: mkdir /mnt/firmware dd if=wrt-11.1.0-r016-1.00.37-r050624.img of=fs.img bs=1K skip=576 3200+1 records in 3200+1 records out mount -o loop fs.img /mnt/firmware mount: you must specify the filesystem type What's the correct -t parameter?
squashfs ... see my previous post above. You'll need to apply squashfs and lzma patches to your kernel. Also what might of interest to some of you is that the TI ar7 chipset used in this router has been used in some similar routers such as the wag54g dsl router and the dlink dslg604t dsl router, both of which have gpl source and toolchains available that should work with the linksys provided source ... but with this being the first GPL'd voip router i'm surprised there hasn't been more interest to hack to the bottom of it at all costs, so at least we can dump vonage and their pathetic, weak service and their gestapo like attempt to keep us using their pitifullly buggy and poor performing firmware. When in fact, the TI AR7 chipset that it's running on is in fact a power demon waiting to be unleashed. This is a DUAL CORE MIPS folks ... TI MIPS32 + DSP620x on one piece of silicon. Here's a link by alec_v... the russian that's done some excellent work uncovering the secrets of this chipset on the dlink: http://www.seattlewireless.net/index.cgi/DlinkDslG604t#head-d5a3fd5b9583fcf9bf091ab9981c156ed98cfcea Reading through it gives a clearer understanding of what's going on with bootloader and some of the stuff rfv3 posted earlier of what he uncovered. Anyway, i hope to have some more time this coming weekend to dedicate to further archeological excavation. If all else fails, I might have to resort to dismantling and adding a serial or jtag interface. I haven't yet since that would naturally disrupt my phone service (which is rather piss poor anyway), but i've also been wondering how to take these newskool cases apart without permanently breaking them. Anyone have any leads on this? :?
Tossing another stone in the water The majority of the information I posted in the past was gathered first hand. The biggest possible breakthrough comes from another page: http://openwrt.org/logs/wrt54g.log.20050716 As mentioned earlier, lzma compression is used on the images, but using 7z or another LZMA compatible decompressor fails. As mentioned in the above post, there is an app called 'adam2' that uses the LZMA compressor and compresses TI images. Since the GPL'd code shows that the chipset is TI based, it would seem to reason that using adam2 (or simply analyzing it) one could actually view the contents of the image (secrets, passwords, etc.) Incase the post above is pulled, the link is listed below, but doesn't include any binaries (alas I've reloaded winxp recently and lost cygwin and gcc, so I havent been able to compile it yet... any takers?) http://www.sensi.org/~alec/mips/adam2_app.tgz
Re: Tossing another stone in the water Hah. Your purported 'biggest breakthrough' was authored by yours truly and if you read through it you'll see i hit a brick wall when attempting to use the adam2_dump utility in its stock form. Perhaps using a recompiled adam2_dump using the linksys gpl'd lzma+squashfs headers provided in the wrtp source might have a different outcome? To Xball: If you were really able to mount comprssed lzma image, any password passed from server would be a cakewalk to sniff. I doubt what you suggested regarding server provided password protection is occuring, but please post a tcpdump log should you find otherwise. Also, please share how you were able to mount lzma compressed image.
here is my step... 1. download squashfs2.2.tar.gz (search google.com) 2. patch the ../linux-2.4.26/squashfs2.2-patch to my kernel ( 2.4.25_pre-gss-r3 <Gentoo> ) 3. down the wrtp54g_cyt_1_00_37.... source from linksys 4. extract it and copy wrtp54g_cyt.../src/kernel/linux-2.4.17_mv121/fs/squashfs to <your_kernel>/fs/ 5.make modules after select squahfs in file system menu 6. then, the squashfs.o is created 7. insmod squashfs.o 8. follow to my old post to split the rootfs image using dd command 9. mount it with "-t squashfs" 10. see the etc/passwd , that is a links file to ../var/tmp/passwd , i think that it is downloaded from server provider... .... this is my experience to share everyone... :thumb:
#18 Today 08:57:36 Ydef Member Registered: 2005-07-03 Posts: 8 E-mail PM Re: Support for WRTP54G Actually, give special thanks to nbd for this breakthrough by doublechecking my original failed attempt and doing it right: http://forum.openwrt.org/viewtopic.php?pid=10723#p10723 We should probably migrate this whole thread and continued dev over there too.
Cool All: Awesome progress at accessing the image; one question though: how do we update the current image on the box? I mean I know that being able to view the firmware we should be able to find holes or passwords, but have any been found yet? I'm still wondering what the SSH pswd is. Also what's up with port 10000? :dog:
I don't mean to discourage and/or discredit what you all have done here with the WRTP54G; however, there is something that I am missing here. AFAIK, squashfs is only a RO filesystem. So, let's assume you can finally compile/insmod the squashfs on you Linux machine and mount the WRTP54G firmware to look at the /etc/passwd file, you still can't decipher and/or delete the password mainly because the password is encrypted and the fs is RO. I just hope anyone can please prove me wrong here mainly because I also want to get the username and password to unlock the Voice menu so I can use my WRTP54G with other VoSP and not Vonage/ATT.
Yes, that's true regarding changing passwords on your current filesystem on the firmware. However, nothing prevents you from making changes to the image (customizing the passwords, thus preventing vonage all-access to your router like they have currently) and then uploading your own customized version of the firmware to the router. In order to do this, you must use tftp. See the following page for additional details: http://openwrt.org/OpenWrtDocs/InstallingAR7
Don't know if this would work... but can you chroot /mnt/linksys /bin/bash then passwd root it?. Just an idea
One thing I could think of is to use the mksquashfs utility that comes with the squashfs package. See if anyone can try this idea as follows: Get a USB drive and plug it into one of the USB ports of your Linux machine. Use the mksquashfs utility to format the USB drive to support squashfs. Mount the WRTP54G firmware through the loopback partition. Copy all files on the loopback drive where the WRTP54G firmware is mounted to your USB drive that has been formatted to squashfs. Edit the /etc/passwd file on your USB drive, and blank the password field for the Admin. Then, use dd to convert this partition to a squashfs image file. Re-flash your WRTP54G with this newly mod firmware. Please take the necessary precaution steps mainly because the modded firmware may ruin your WRTP54G unit. Good luck and please report back here.
A bit off topic question here: Does anyone know what is the filesystem used under the Linksys PAP2 firmware? If it is also a squashfs, how does one go about to determine the skip number for the Linksys PAP2 firmware as shown below for the Linksys WRTP54G firmware: If Linksys PAP2 firmware doesn't use a squashfs, does anyone know what FS does it use and where to get the FS source code used under Linksys PAP2 firmware to compile under Linux? BTW, do Linksys PAP2 and SPA2K Firmwares use the same FS? If so, what is the filesystem used? Can we get the source code of such filesystem under Linux?
I followed exactly you described above, except I tried it with linux-2.4.31 kernel. My result was no good where SQUASHFS complained with the following error messege: Code: SQUASHFS error: Can't find a SQUASHFS superblock on loop(7,0) Perhaps, the firmware I downloaded from vonage TFTP is encrypted. If that's the case, can you at least tell me the link to download the firmware and/or perhaps mail me a copy of the firmware you have?
Passwords As seen in this post, the default passwords are as follows: ABsFuZ3PufkXY:user AB2ChJScbtR5I:admin Additionally ydef brought back up how a new config.xml is also automatically downloaded. Unfortunately my laptop, which was used for much of my work on my router, has fried.* More specifically I lost my dump of the traffic between the router and linksys. I do recall though that the xml files requested included the mac address... it was something like macaddress+somenumbers.xml. As the filename included my mac address, I 86ed the exact file name from my documentation in my original post. There is two key points I didn't even think about when it comes to how the router boots. First, as the router always asks for the newest XML file after a reboot, you should be able to, at least in theory, set up your own tftp.vonage server (run your own dns/tftp server internally) and upload a new xml file (using the TI/Adam2 encoder). Second, a hard reset should clear out all passwords... possibly including those downloaded in the xml file. If the xml passwords are infact reset, you should be able to ssh in with the username "Admin" and one of the passwords above (user/admin). (I'll be trying this shortly). *External temp was > 120F and the laptop in general is jacked
I tried the default passwords after I restored the factory defaults and had no luck. I've heard with adam2 devices that the default IP is actually 192.168.2.1. Maybe as the router boots someone can get in via tftp on 192.168.2.1 using one of the previous mentioned passwords? I've heard of "adam2" and "adam2" being used as user/pass. I suppose it may all be moot as I've heard talk that even though TI developed parts of the wrtp54g, it isn't based off of the adam2.
That's right... it uses PSPBoot. I'm still curious to know if anyone's actually managed to compile an image from that GPL'ed sourcecode. I've made a few half hearted attempts and can't seem to find all the right places to put the config files. I read here: http://www.linux-mips.org/wiki/AR7 that TI didn't release certain portions of their source. Is that perhaps why we can't compile our own firmware image? How about mouting the image from Vonage, altering the appropriate files and repacking? Anyone know how to do that?
Yeah, PSPBoot According to this page: If this layout is consistent with the binary on the WRTP54G, some comparison of the boot loader might reveal how this one was locked down to prevent JTAG users from pressing escape. Anyone down for a binary diff of the two images (at least when it comes to the two PSPBoot binaries)? The idea is that by patching the bootloader on the current firmware, we can gain access to extra features. Once patched, simply upload it back to the device via the html interface Sigh, I want the ssh password. (Heck, I'd be happy with the ssh hash. :wallbang:
On an rtp300 with 1.00.50 firmware the config backup is a zlib compressed file starting at offset 0x14. The ssh username (Admin on my box) and des password hash are contained within.
I have this same VoIP router. Is there a way that that hex offset can be read through the web interface or an open TCP/UDP port somewhere?
