Our office has a number of these Polycom SoundStation 2W devices, and until last month they all worked pretty well. They’re basically a DECT version of the venerable SoundStation 2. (You can in fact throw away the Polycom base-station and replace it with a SIP enabled one and get an excellent cordless SIP conference phone). In the version of the firmware ours had you could even use two of them at once with the same base station at the same time to get better coverage for a large room.
If you know much about DECT that last statement should have you worried: how do two devices manage to get the same randomly generated private key? That question has one obvious answer.
There’s not much hardware available for playing with DECT. You could use an SDR and I’ve a goodly number of them, but I’m not aware of there being a particularly good stack. The answer is a bizarre evolutionary dead-end of wireless technology: the idea was that you got a special DECT base station, hooked it up to BRI ISDN port, put one of these or one of these
in one’s PC, and then, one could surf the internet at a blazing 128 kilo-bits a second (or your could share and two could get 64 k) – all without wires. [These things come up on eBay every now and then if your’re curious, I paid €47 for one and a PCI to PCMCIA bridge to put it in]. Once you have one of these and have coaxed the Linux driver into working there’s a goodly selection of software to play with. I used dedected.
There are a few alarming things you’ll discover when you start poking the various bits of DECT hardware you own. The ones that got me were that key presses on the handset are sent en-claire even if the audio is encrypted, and if you have a plurality of manufacturer’s handsets connected to a base station it’s quite likely that your audio isn’t encrypted either.
From the research i did the Polycoms did appear to have a fixed key, but it’s rather hard to generate a known plain-text using a microphone. Fortunately they do have a mini USB port, and I was led to believe that if I upgraded I’d get encryption. Polycom provide, once one’s fought their CMS and agreed to export restrictions, the latest firmware upgrade, so this should be a simple upgrade. However this is Polycom and some caution is required.
To this end I purchased another console (the bit that looks like a Frisbee) from eBay and applied the firmware update to it. It took a few goes, as there’s a goodly number of race conditions between windows installing drivers and upgrade waiting for a response from them but the experience was mostly painless. I then connected it to one of our base stations and it worked, but then the misery started: one by one the other consoles in the office lost contact with their base stations and refused to talk to them or register any more. Worse the option to pair with a DECT/GAP base station had disappeared from their menus. Woe. Caution had failed me. I tried giving the same new firmware update to the sick Polycoms, but without success.
Internally the 2W has a Xilinx CPLD, a TMS320 which is the main CPU and a DECT “Cordless Voice Module” SC14CVM. The TMS320, its RAM, ROM and JTAG connector are all hidden under a particularly-well-soldered-on screening can. What you can easily get at, is a small I2C EEPROM, an at24c32, that sits on the CVM. Swapping the contents of this ROM between the working and not-working consoles didn’t, however, bring any joy.
The next step was to tear apart the firmware: fortunately the firmware updater leaves this lying around in conventional formats. strings(1) on the TMS320 firmware isn’t initially rewarding until you remember that the TMS320 has 16 bit words and so you need to use the “-e l” option to strings. Looking at the output of strings there are two hidden menus in the firmware: one looks to be for test, and the other for diagnostics. It took a few minutes of finger pressing to find out how to get into them: Holding the up-arrow and star gets you into the tests menu, and holding the down-arrow and mute gets you into the diagnostics menu.
From here you have a few options: one allows to read and write values on the CVM EEPROM either in the console or the base (That explained how our rogue console managed to kick everyone else off.), another sets a country code.
The working Polycom had a country code of 22000205, all the others had one of 0. It appears that 0 is the default. The consoles appear to set the country code of any base stations they find to their own, and will only pair with base stations that match their country code or have country code 0. Programming our remaining consoles with 22000205 brought them all back on line. All but one of them then took the new firmware update, and their missing options all came back.
The one that didn’t was on such an old version of the firmware that the updater wouldn’t update it. Much Googling revealed that we needed an intermediate firmware version from Polycom. Polycom only deal with resellers so that wasn’t a solution. So off came the screening cans:
My first plan was to clamp a high-ish address line of the ROM during the two seconds at boot when the bootloader CRCs the firmware image in the hope that, after noticing the image was corrupt, it would then go into a recovery mode and the update software would take it from there. When I tried, the bootloader duly noticed and did go into a please-upload-new-firmware loop. Unfortunately the firmware updater still didn’t want to play. No dice.
My second plan was to solder a header onto what looked like a standard TMS320 jtag port and see if I could make any sense of the ROM contents. Despite my best efforts nothing could get what should have been the TDO pin to budge, again, no dice.
So that just left the third option, take the TMS320’s ROM off. (It’s an Am29LV400BB. Which tells us that the bootloader is at the beginning of the ROM.) So I did that, connected it to my TL866 programmer and read out the contents. I looked at the layout of the data. It matched what I was expecting. So I created a new ROM, by taking the bootloader from the update software and combining that with the application that I had just read from the ROM, but with one English word in the application changed, so the CRC would fail.
I tried programming the flash, but my TL866 said “No”, and that made me sad. I tried flashing the original contents of the ROM, and the TL866 said “No” again: more sadness. After poking at the rom with a scope it appears that the TL866 doesn’t cope well with ROMs that have a BYTE# pin and thus can change between 8 and 16 bit widths. Disconnecting that line from the programmer and shorting it to VCC made the programmer happy.
However, now I realized that every other byte in the copy of the firmware I had taken was corrupt. In desperation I tried flashing the complete firmware file onto the ROM, and soldering the ROM back into the Polycom. Nothing. Not even an LED. Still no dice.
Finally, not relishing the prospect of getting another screening can off to get a good copy of the ROM from one of the other Polycoms, I realized that the firmware files had a 4 byte header giving the length of the file. Stripping that off, de-soldering the ROM, re-flashing, and re-soldering got me a Polycom that booted, but wasn’t so happy. I then re-flashed it to program in the new CVM firmware, and it worked like a charm.
Eugh