The Cisco 7970 is a black box piece of hardware and as such there is very little information about it on the internet. Cisco pretend it’s a closed appliance and as such go out of their way to prevent people for using the in a more flexible manner.
As of late I’ve been doing quite a bit of Cisco phone trickery. I’ve gotten a network of Cisco phones working with Asterisk and I’ve been building up sleek looking XML services for the 797x models. What I really want to do, though, is delve a little deeper into the spirit of hardware hacking and see if I can properly customise the phone beyond what is possible with configuration files.
The Cisco 7970 is based around a Broadcom BCM1100 IP Phone Processor which includes a R3000 MIPS32 core running at 100mhz and a DSP running at 140mhz. This single chip provides the bulk of the functionality required by the phone. Attached to this core is 32MB of DRAM and 16MB of Flash Memory.
Behind the scenes the phone runs on a proprietary unix-like operating system called CNU-OS. Running the command uname -a emits the following,
CNU6-OS 8.5(2TH1.9) 3.3(0.3) CP-7970G BCM1100-C1(MIPS32)
The operating system provides a multitasking environment on which the phone software runs. It, of course, mostly runs on Java.
Unfortunately for would be hackers *cough* the Superuser account is barred from regular access by a random password generator. Attempting to access the Superuser account, either from the login screen or via the su command, results in the following
$ su
challenge: ZTHPLNFJ password:
Invalid Username/Password Entry.
challenge: XZLDHZGX password:
Invalid Username/Password Entry.
challenge: KCKVNLNQ password:
Invalid Username/Password Entry.
The challenge value changes with each attempt. The challenge value is always an 8 character uppercase letter only string, though. It is also in exactly the same format as the passwords encoded in the /etc/passwd file. From this I make a few assumptions regarding the root challenge
I never let a lack of superuser access prevent me from doing what needs to be done. Surely having physical access, not to mention ownership of said phone, endows me with the right to do with it what I wish? Apparently not. I came up with an interesting idea for granting full filesystem access to any user.
During the phone boot process it runs the /etc/init.tab script which performs a number of tasks like mounting the partitions and starting the various services. Since this is a fixed platform there isn’t much need for automated scripts. I had the idea of replacing a less important command with a ‘chmod -R 777 /’ command to grant read, write and execute permissions for everybody to everything. It’s a little hackish but that doesn’t really matter. The only problem is that you can’t edit the file in place on the phone (because of a lack of permissions). The file *is* editable when it is still a part of the phone load. I cunningly edited the phone load file (jar70sccp.8-5-2TH1-9.sbn for anyone interested) which contains, among other things, the init script I wished to edit right in plain text.
I forced the phone to reload the firmware from TFTP and was met with Cisco’s next roadblock to hacking goodness. The SBN file, which is a Signed Binary, was no longer valid. Since the file is not encrypted I can only assume at this stage that the file contains a checksum of some sort that became invalid when I updated the necessary file.
That still remains an interesting vector of attack. The SBN file format is not that complicated looking and the bulk of the file data is the very files it contains, stacked one after the other.
Now I am working on deciphering the SBN file format so that I can create tools to build by own phone loads. There is a lot of potential for customisation. All of the phone’s graphical assets are stored in a number of PNG files which are easily editable.