Introduction

If you’re here, it’s probably because you bought an SPA122, you reset it and now you can’t log into it anymore, even though you had no clue that it was ever locked (especially if you bought it on eBay). I think this is because a lot of “unlocking” for these things just resets the password, but it goes back to the way it was after a factory reset. Fortunately there’s an answer to that, if you keep reading below. If you own a SPA112, they look to be about the same thing, only the latter doesn’t have routing built-in. Also, if you do any of this stuff, you do so at your own risk, and it may void the warranty.

I ended up in this situation after buying a SPA122 on eBay for US $30 as part of my faxing project. While these devices are end of life, it was only in 2020, so the software is reasonably recent. The seller said it was working, and nothing was mentioned about it being tied to a phone company already. Everything seemed good. Everything was not good.

Trying to set up the SPA122

When I got this device in the mail, I plugged it in to both a network and a phone. To reset it, I did the standard thing where you pick up a phone receiver, dialed ‘*’ four times to get the voice prompt, and then ‘73738#’ (the letters for RESET) to reset it. After waiting for the lights to finish blinking, I dialed four stars again to get the voice prompt, and then ‘110#’ to get the IP address. I’ve read that it’s less dangerous to do a user reset in this situation, but you still have to worry if anyone eventually does a reset on hardware like this.

After doing a reset, I went to a browser, put in the IP address, and typed the default username of ‘admin’ with a password of ‘admin’, but was greeted with “Invalid Username or Password. Please Try Again.” I also tried the default user username of ‘cisco’ with a password of ‘cisco’, but that did not work either. I unplugged the network, did the reset again, and then found that while the admin user did not load, the user account seemed to work this time.

Logging in as the regular user was enough to see under the Voice / Information / Product Information screen that it had a customization for “BigRiverTelephone”. In other words, this was a box that was given or sold to someone by the Big River Telephone company, locked to them, and not usable with Twilio as I’d hoped.

Resetting the ‘admin’ password

I looked around for a way to log in as admin, and stumbled across a forum post entitled Unable to access SPA122. Someone there pointed out that there is a way to unlock a SPA122 for use with any provider via a serial console.

I went to that blog post and the instructions seemed promising. You can hook up to the serial lines on the J2 connector and change the password for the web console on-disk, which lets you reconfigure the device. The screws are under the feet, and while mine were pretty well stuck on, I was able to remove them without tearing the rubber. My J2 pin header was already populated with pins, which I suspect may be true for all the locked models given the excellent quality of the solder work.

While I didn’t have a level shifter or usb serial cable that does 3.3V TTL serial (as required for talking to it over serial), I did have a Raspberry Pi Zero W handy, which is easy to wire up and only costs $10.

If you decide to use a Raspberry Pi for unlocking, you’ll want to start up raspi-config, go to ‘Interface Options’, ‘Serial Port’, disable the shell, but enable the hardware. On the SPA122, the J2 pin header contains the serial pins. Pin 2 is TX on the SPA, so you’ll want to hook it up to the RX on the Pi or Pin 10. Pin 3 is RX on the SPA, so you’ll want to hook it up to TX on the Pi or Pin 8. Pin 5 is ground on the SPA, so you’ll want to hook it up to any of the ground pins on the Pi, but pin 6 seems pretty sensible if you’re hooking up serial to the adjacent two pins.

Once you’ve got it wired up, you can test to see if it is working correctly by looking on the serial port at 115200 baud. Using screen for that on the Pi is as straightforward as screen /dev/ttyS0 115200, but some folks prefer minicom. If you restart the SPA122, you should see some text scrolling across your screen. If you hit space before it gets out of u-boot, then you’ll get dropped into the bootloader. Fortunately for me, all my wiring was correct on the first try.

From the bootloader, you can get into single user mode with busybox like so:

setenv bootargs $bootargs init=/bin/sh
boot

You can bring up mdev (the busybox equivalent of udev) for accessing device nodes, including memory technology devices (mtds) like so:

mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t tmpfs -o size=64k,mode=0755 tmpfs /dev
mdev -s

You can also see what the partition map looks like with cat /proc/mtd. The author of the original post pointed out that you can change the password of the admin user to the default like so:

# Mount the nvram partition
mount -t jffs2 /dev/mtdblock9 /nvram
# Backup the nvram data (though this will get wiped later anyway)
mv /nvram/nvram.data /nvram/nvram.data-old
# Use sed to replace the hashed password of the admin user
sed -e 's/admin,enc=.*,0/admin,admin,0/' < /nvram/nvram.data-old > /nvram/nvram.data
# Unmount nvram
umount /nvram

I found that actually un-mounting the nvram didn’t seem to work, and reboot wasn’t implemented, so I did a sync; sync; halt to shut down the system before unplugging.

Fully unlocking

Following those directions got me into the admin web user, but the device would re-lock if you reset it, which wasn’t ideal. From the console logs I could see that the nvram data got deleted on a reset, so that clearly wasn’t where the encoded password was coming from. My guess is that it would be where there would be factory customizations, and that the most likely place for that is ca_data partition.

If you go look in that partition, e.g.

mount -t tmpfs -o size=64k,mode=0755 tmpfs /tmp
mkdir -p /tmp/ca_data
mount -t jffs /dev/mtdblock10 /tmp/ca_data

You’ll see that there are some certificates and some other files.

For fun, I looked at the certificate there, which is base64 encoded DER. If you base64 decode it into a DER file, and do something like openssl x509 -noout -text -inform DER -in example.der, you’ll see something like:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            <snip>
    Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, ST=California, L=San Jose, O=Cisco Small Business, OU=Cisco Small Business Certificate Authority, CN=Cisco Small Business Client Root Authority 1/emailAddress=ciscosb-certadmin@cisco.com
        Validity
            Not Before: Oct 16 00:23:31 2013 GMT
            Not After : Oct 26 00:23:31 2044 GMT
        Subject: C=US, ST=<snipped mac address>, L=<snipped serial number>, O=Cisco Systems, Inc., OU=cisco.com, CN=SPA122-RC, MAC: <snipped mac address>, Serial: <snipped serial number>/emailAddress=ciscosb-certadmin@cisco.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    <snipped>
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                Product is SPA122-RC
            X509v3 Subject Key Identifier: 
                <snip>
            X509v3 Authority Key Identifier: 
                keyid:<snip>
                DirName:/C=US/ST=California/L=San Jose/O=Cisco Small Business/OU=Cisco Small Business Certificate Authority/CN=Cisco Small Business Client Root Authority 1/emailAddress=ciscosb-certadmin@cisco.com
                <snip>

            Netscape Cert Type: 
                SSL Client, SSL Server
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
    Signature Algorithm: md5WithRSAEncryption
         <snip>

It’s not clear exactly what this is used to do, but my guess is that it was generated when this hardware was manufactured, probably October 2013.

Anyhow, back to unlocking, there were two interesting files in the ca_data partition: custom.dat and flat_profile.xml.

The first, flat_profile.xml, contained something very similar to this:

<flat-profile> <router-configuration> <Web_Login_Admin_Password>some-password</Web_Login_Admin_Password> </router-configuration> </flat-profile>

Upon trying the password listed, I was able to log in as admin, so this made it obvious that I was on the right track. I tried inspecting custom.dat, but it looks like binary data of some sort. My guess from the name is that custom.dat contains the configuration that locks it to a specific telco.

I moved both flat_profile.xml and custom.dat to a new set of paths on the same partition to back them up, and did another factory reset. This time around, the admin password stayed as ‘admin’, and the customizations showed as ‘Open’. The device now seems to be fully unlocked. In other words, those files provide the locking / customization, so deleting them or making them where the system can’t find them restores you to stock. Success!

Final Thoughts

It seems like there was a conscious design decision to make this board easy to customize at the factory. My guess is that the pin header is there to make it easy to reprogram without requiring a pogo pin fixture. Having the files that do the customization sitting around in a way that is easy to modify from a serial console isn’t ideal from a security perspective, but probably makes programming easier.

It’s unclear to me if the admin password for this device is shared across all models from a telco, is specific to that device, or somehow derived. It would be interesting to buy a few and take a look.