TFTP Server?!

Yesterday, I tried to hack my DVD player and set it to a different region code, so that I can see the movies that I bought when I was on the other side of the Atlantic. The attempt failed; however I was surprised how much technical detains you can find on such things like DVD players on the net, if you use the search-engine-of-your-choice for a few minutes! I must have missed a couple of years in DVD player development, this device that I bought has an Ethernet connection and yes, it is a beast with web browser, web radio and all kinds of stuff! So, I decided that today’s blog goes really into the technical details of the snom m9 under the hood. No reason to reverse-engineer it! I don’t think you have to “hack” anything on the m9; we try to make the features accessible for you as easy as possible (especally, dont try to change from US DECT to ROW dect, this will just screw the device up). But it is always good to know a few tricks that can make your life easier in case of trouble.

One of the major changes that came with the 9.4 version was the inclusion of a TFTP server. Yes, server! You might think, shouldn’t it be a client? The answer is the m9 as both a client and also a server. While the client is primarily used to pull down the configuration information and the firmware (if you don’t want to use the HTTP or HTTPS protocol), the server has a different function.

In contrast to the desktop phones, the m9 base does not have a display, so there must be a different way to recover the base station in case of trouble. Relying on the handsets is not an option, e.g. because the PIN go lost or there is some trouble going on with the handsets anyway. That’s why we included the TFTP server. In case of trouble you can use it to push the right firmware (back) on the device and don’t have to RMA it.

TFTP is very simple, but not very safe by nature. So keeping the TFTP server wide open all the time was not an option. Instead, the m9 opens the TFTP server only for 20 seconds after a fresh reboot and it only waits for the writing of one file: auth.txt. This file must contain the username and the password, which you would also use when logging into the web interface. For example, the file could look like this:

# Samle auth.txt file
username: admin
password: password

So in other words, in order to use the TFTP server you must know the username and the password. Once you got it, you can read and write all files in the file system. You are in full control! For example, you can make a backup of the files that are in the /nv directory (which stores all “non-volatile” files). One special file is the private key of the device. In the /nv directory you will find the privatekey.txt and certificate.txt, which contains the keys for the device (every device has a different one, and it depends on the MAC what is in the certificate). It is a good idea to grab the private key and also store it in a safe location. Because if you should forget about the username/password or some idiot changes it without letting you know, you can still unlock the TFTP server by writing the privatekey.txt file with the exact content of the private key. As you probably know, private keys are not supposed to leak out, so be sure you store it in a really safe place! Talking about security, you should also keep in mind that TFTP sends the packets unencrypted; so you must be sure that no one is running Wireshark in your network while playing with the TFTP server…

In the /nv directory, you typically find those files:

• adrbook: This directory contains the address book entries.

• ata-app: This is the main application that e.g. runs the SIP stack and the web server
• ata-ctrl: This thing is responsible for getting the m9 up and running. This one runs the TFTP server and other network services.
• ata-media: This program is responsible for the RTP processing.
• base-type.txt: Here the m9 keeps track what DECT version it is (e.g. us or row for USA and the rest of the world)
• base.bin: This contains the firmware for the DECT module
• base.txt: The short version text for the DECT module. If this one is different from the one being reported during the boot phase, the m9 will perform a software update for the DECT base station.
• certificate.txt: This file contains the certificate for the device.
• dectvoice.ko: This is the driver for the DECT module.
• dhcp.info: Here is some additional information that cannot be stored in the resolv.conf file.
• handset.bin: This is the firmware for the handset
• handset.txt: Short description for the handset firmware.
• handset17.bin: Because there are two handset versions out there, this one contains the firmware for the new “17” version handset.
• handset17.txt: Short version name.
• html: This directory contains all the HTML templates for the web server.
• mac.txt: This file stores the MAC address for the device.
• privatekey.txt: This file contains the private key for the device.
• random.txt: Here the m9 stores the last random number, so that every reboot cycle comes up with a new random number.
• rc.snom: This is the bootup script for the device
• resolv.conf: This links actually to /etc/resolv.conf and is used by the standard programs to find out about DNS
• rfpi.txt: This file stores the RFPI number for the base (DECT stuff)
• serial.txt: Stores a serial number from production.
• settings.xml: This file contains all the settings for the device.
• version: In this file, the m9 keeps track which firmware version has been loaded.

I would copy all files that are there, so that later, if you are experiencing trouble, you can always copy the files back and resume from this point. If you like, you can also put your own certificates and private key on the device this way. Playing with the MAC or the RFPI does not make sense to me; I don’t think you will get anything out of this. But it might be fun to change the HTML pages, for example if you have a customer who should not see everything.