Hacking The 3Com 3C19504:
Investigation Log

Christopher Rath

May–June, 2002

C A U T I O N

Most of the actions I describe herein result in the voiding of the device’s warrantee. I take no responsibility for any damage which might result from anyone attempting to duplicate my work. In other words, you bear all responsibility for your own actions. If you break your 3C19504 then it’s your own fault. I do not recommend you reproduce my work! This information is offered for entertainment purposes only, no warrantee is offered or implied.

The Gory Details

I started by plugging in and booting the 3C19504 as per the owners manual. I set it up to run on my home network, as though I was only going to use the file server and web server functions. Once I had verified that everything was OK (i.e., that it was DOA) I proceeded with my experimentation.

The first change I made was to remove the cover from the VGA port. The cover was held in place with Torx screws and was easily removed. I then booted the 3C19504. The following three screen shots—taken with a digital camera—show the start of the boot sequence (click to expand the photos):

  • First Boot Screen Capturefrom this shot we can see that the 3C19504 is using an AMI BIOS, version UC612C.
  • Second Boot
        Screen Capturein this shot we can see the Fujitsu MPG3102AT E hard drive being detected
  • Third Boot Screen Capturein this shot we see the BIOS summary screen and the LILO prompt
  • here we also see that the system only contains 32 meg of RAM; suggesting that if performance suffers later, some extra RAM might be in order

Making The Box Accessible

In order to facilitate ongoing support of the box by me, I want to be able to telnet into it from the home LAN side of the server (when it’s operating as a firewall, one NIC is on the Internet/WAN side, and the other NIC is on the LAN side). I would like to be able to telnet into the device and then su to root in order to make configuration changes. It turns out that if one ticks the “Enable Remote Management using permanent Internet connection” option on the 3C19504’s System ® Admin Access section in the configuration tool then the device will start the telnet service.

Once telnet is running, the next step is finding a userid/password combination that will give you access to the box. In order to get access, I found it necessary to remove the hard drive from the 3C19504 and mount it on another Linux machine. Since my home PCs run MS Windows 2000 and NeXTSTEP, I needed to get creative: I downloaded an ISO image of a bootable Linux CD and booted my home PC (a Dell) from that.

To create the bootable CD I used the Red Hat v6.2 bootable ISO image called SuperRescue CD; maintained by H. Peter Anvin. I used his version 1 release as it was closest in version to the 3C19504’s Linux version; however, his version 2 looks absolutely fabulous. The CD just worked, first time out, no trouble. What better recommendation can I make?

On the 3C19504’s drive I found 5 partitions (I’ve also listed the device path used to mount that partition under SuperRescue):

  1. The boot partition [/dev/hda1]
  2. A skeletal directory structure [/dev/hda5]; it looks like the other partitions are ultimately mounted into this one
  3. The system files [/dev/hda6]
  4. The user files directory structure, and some other supporting files [/dev/hda7]
  5. Swap space [/dev/hda8]

I initially mounted the partitions in read-only mode to ensure I didn’t mess something up. Then I mounted /dev/hda6 in read-write mode and edited the /etc/password file: I removed the password crypt for root’s entry, and I added an extra entry of my own with user and group ids of 0 (i.e., I made it a clone of root). Then I put the drive back into the 3C19504 (after unmounting and shutting down, of course).

I then found that while I still could not log in as root or login using my new userid, I could ftp in using my newly added userid. Thus I now had a way of changing any file on the system; which means there would be no further necessity to mount the drive on another system in order to hack its files.

Toward Access Via Telnet

Now that I was able to log into the 3C19504 using FTP, this facilitated working on it using XEmacs and EFS mode.  An exploration of the system configuration files in /etc showed that Pluggable Authentication Modules (PAM) are being used for security, and not just default UNIX security. 

Notice how authentication is only to be done using the the Password Database Library; thus explaining why I was unable to login to the device even after I had created an entry in the /etc/passwd file.  The puzzling thing is that no password database appears to exist on the system, and no /etc/shadow file exists.  I rectified by patching these two PAM /etc/pam.d files as follows (highlighted lines are new, the trailing lines of the files have been truncated):

The net result of this change is that I was finally able to telnet into the 3C19504 using my new userid.

Installing A Larger Drive

These days, a 10 gig drive is not very big. Since the 3C19504’s OS consumes 2 gig, that leaves 8 gig as user-usable. I have received correspondence from one individual who has swapped out the original hard drive for a 20 gig drive.  I have myself attempted to install a 40 gig drive, and that causes the POST boot-up test to hang; which appears to validate the manufacturer’s claim that the largest drive supported by the BIOS is 32 gig (as noted in the next paragraph).

I emailed the tech support contact provided on the FIC homepage asking what the largest hard drive supported by the AMI UC612C BIOS is. FIC tech support responded within 48 hours to say that 32 gig is the drive limit for that BIOS.  I wasn’t happy with the manner in which I had posed my question to the FIC tech., because I had mentioned the 32 gig limit in my question.  So, I dug deeper.

Third Boot Screen CaptureI queried a couple of individuals more knowledgeable than I about BIOSes and Linux.  One of them turned up the following information on IBM’s website: Getting beyond the ATA 8.4 GB limit.  I spent a few minutes looking at the various drive types supported by the BIOS, but none of them is useful in out current world of multi-gigabyte drives.  The screenshot to the right shows one of those drive settings.

My own experience shows that a 40 gig drive will not work with the BIOS (it hangs the POST).  Since conducting this initial investigation, I have upgraded the drive.

To be sure that one is able to use a drive larger than 8.4 gigs, it is probably necessary to ensure that the Linux boot partition is fully contained within the first 8.4 gigs of the disk.


©Copyright 2002, Christopher & Jean Rath
Telephone: 613-824-4584
Address: 1371 Major Rd., Ottawa, ON, Canada K1E 1H3
Last updated: 2007/02/16 @ 09:53:03 ( )