Retired, Teardown: Uniden XSA660 Analog Cordless Phone

On the whole, the rapid pace of technology means that, inevitably, there will come a time when you will need to upgrade to newer devices. But some systems have stayed the same for so long, that sometimes they escape being replaced even when they really should have been taken out of service years ago.

A primary example was my two-handset Uniden XSA660 analog cordless phone. This unit was purchased second hand, but is believed to have served 14 years on its original batteries. By the end, the batteries were still good for >1 hour of talk-time, and the coverage was still “adequate” for a small house. Given how rarely our (now VoIP) landline system is used, I almost didn’t bother to replace it until I realized how inexpensive a modern Uniden DECT 1015 was.

Now that the XSA660 has officially retired from service, it’s probably a good time to do an “end of life” teardown to compare and commentate on how cordless phone technology has evolved.

The Base

2016032821272840 2016032821282841

The whole Uniden package is unlike the modern-day Unidens even though it was Made in China. The casing itself is solid, made of thick and well-fitting plastic parts with screws tightened so well that they take some effort to undo. The base is a rather ordinary looking unit by modern standards, but was a mid-range premium unit at the time of sale. We can tell this because of the integrated digital answering machine (no microcassettes) with remote control access and a speakerphone conference facility on the base itself. The answering system has an RTC-based time of day and day of week timestamping. The system also permitted random-access delete of messages. A paging facility is also provided to ring the handset so you can find it (if it still has power – standby time is nominally 10 days, but gets worse as self-discharge increases as the battery ages). It probably wasn’t the top-of-the-line as those may have already had LCDs and caller-ID display which is now practically standard.

There is a position for the handset to be cradled for charging, where two “ball-bearing” shaped contacts make connection with the rails on the handset. The rear of the unit has some information about how to set-up the two handsets – as far as I know, the technology supported a maximum of two handsets at the time. The handset number is programmed into the handset, but the base also needs to set certain parameters (more on this later), hence the need to place the handset onto the main base.


2016032821302844Power and telephone line are connected to the rear, and a ringer on-off switch is provided as well, although it seems only to turn off the ringer on the base. The handsets still ring regardless, which was a little perplexing to me. The side offers a selection of automatic answer ring times – two rings, four rings or toll-saver.

The toll-saver feature changes the number of rings to answer depending on whether there are any messages. As a result, if you are calling long distance and the machine doesn’t pick-up within four-rings, you know no messages have been recorded and can hang-up before you get charged. Otherwise, the machine would have already answered, and you can enter remote-control command to retrieve/clear your messages using a touchtone keypad and the following commands:

  • Enter # and pin code during outgoing message (the default message sounds like this) to enter remote control operation, default is 80.
  • Time and day stamp is announced along with number of messages.
  • Enter #1 to repeat, #2 to play message, #3 to skip, #4 to delete, #5 to stop, #6 to turn answering machine on, #7 to record a memo/stop recording a memo, #8 to record/stop recording an outgoing message, #9 to turn answering machine off (and lose subsequent remote control access), and #* to switch to room monitor mode.

No voice prompts existed, as that would probably have made the device quite a bit more expensive, which makes the system difficult to use without a reference card. The system also likes to hang up on you if you don’t enter a command within 2 seconds. It’s no wonder why such systems weren’t commonly remotely used.

The record time switch allows you to limit the length of each of the messages to avoid callers monopolizing the on-board memory which is relatively limited and not expandable (15 minutes).

Unlike modern higher-frequency cordless phones, this unit has a telescopic antenna which stretches about half-a-meter, and needs to be fully extended in service.

By undoing four screws, we can look inside the unit.


The front cover is home to the speakerphone speaker – a 0.2W unit, the charging contacts and the front panel controls which connect by ribbon to the DSP board. We can see how small plastic posts are moulded in to guide/hold hook-up wires, which is a nice touch!

2016032913172847 2016032913172848

The board is similar to remote controls – elastomer rubber button overlays on top of serpentine-traces coated in some carbon-like compound against oxidation. Two 7-segment displays and LEDs are used for indication.


The lower part of the shell comprises of a paper-type PCB, dated week 34 of 2002, a microphone PCB towards the bottom, and a DSP module dated Week 42 of 2002. The DSP module has a good amount of shielding around it, likely to prevent any digital interference to the analog sections which could reduce the range of the device or introduce annoying buzzing at certain frequencies.

2016032913222850 2016032913232851

The DSP unit has an Agere line codec, and an Agere DSP (I suspect). The Uniden branded IC probably performs most of the control features, whereas the Samsung DRAM (512kBit x 8) stores all the voice data. In case power is lost, all messages are lost, as no power back-up is provided. Flash was probably a bit too expensive for this application and an endurance issue especially under heavy usage or using a small chip with no wear levelling.


Nothing particularly interesting is hiding under the DSP module. On the main board, we can see a lot of adjustments, as you would expect on an analog radio. Most of them are nicely marked – RT1 (SQ) I suspect stands for squelch or signal quality, RT2 (RX Level) probably sets receive level. Many of the adjustable ferrite slugs are used to set the tuning of filters, and the tuning of the transmitter/receiver. As these are “mechanical” devices, they are subject to drift over time, so performance will likely degrade slightly especially when subject to harsh temperature swings or mechanical stress/vibration.

The base uses a reed relay switch, labelled Bestar in a green tube. This type of relay is rarely seen outside of telephony and doesn’t seem to be a common type of relay, but basically uses a magnetic reed switch (similar to those used in alarm door sensors) consisting of magnetic contacts sealed inside a glass tube, and an electromagnet winding around it which can cause these contacts to open/close on command. Because of the sealed contact nature, it is not prone to oxidation/corrosion that would need some current flow to burn-off.


The underside has two main ICs of interest. Both appear to be custom chips, the top one “lacquered” over to make it hard to identify, and the bottom is a gob-top mounted on a carrier which was then mounted onto the PCB similarly to the one in the DECT 1015. It was surprising to see this sort of technique being used.

The Second Handset Charger

2016032821232832 2016032821232830

The unit came with a second handset, which had its own charging cradle.


Internally, it is a very simple device without much inside. In fact, the PCB isn’t likely to be entirely necessary either.

2016032821252835 2016032821262836

Charging occurs by routing the incoming 9V 350mA supply though R301 (220 ohm) to the handset. Basically, it’s a crude current limiter – assuming a fully charged cell voltage of 1.45 x 3 cells = 4.35v, the voltage across the resistor would be 9 – 4.35 = 4.65v and the current flow to keep the cells topped up would be 21mA – or about 0.07C (less than the recommended 0.1C for Ni-CD cells, making it safe for indefinite charging).

The Handset


The handset (bottom) is a little larger than the modern DECT 1015, but what really makes it stand out is the long antenna that sticks out of the top.


The phone has basic features, including an LED backlit rubber-keypad. Unlike some higher end devices, this doesn’t have speakerphone capabilities on the handset.

2016032821152820 2016032821152821

2016032821152822Opening the battery compartment shows exactly the influence of time – the rubberized foam had completely disintegrated into a tarry substance.

The battery pack appears to be a 3.6v 300mAh Ni-CD made from 3 x N-size cells (not AAA as claimed in the manual).

Getting inside took unscrewing two screws in the battery compartment and carefully prying around the edges.



Internally, we see what is essentially a “counterpart” to the base shrunk down into a portable package. A very similar arrangement of variable inductors, resistors and ICs are seen, and this because the analog cordless phone is essentially a “paired” transmitter and receiver on both sides.

2016032821192824 2016032821192825

Interestingly, we can see the ringer is positioned next to the microphone. If ringing came out of the earpiece, it’s likely you might accidentally deafen someone unexpectedly.


The speaker area seems to have a metal grille grounded as well, probably to avoid RF interference affecting the audio amplifier, or maybe try to use the “human” as a counterpoise for the short stub antenna?


Again, it was very nice to take a close-up look at the radio section where the silkscreening was quite informative, which would make servicing easier. It also illustrates how sensitive these handsets may be to being dropped …

Testing & Comparison

Now that this set is no longer in service, it would be an ideal time to actually test the unit and see just how things “work”. Ultimately, this probably won’t be exciting to anyone that’s ever owned a scanner, but it’s worth revisiting.


The base station uses 30.075-30.300Mhz to transmit to the handset (10 channels) in Australia. The transmission is basic narrow-FM mode, so any scanner or SDR can easily receive it – in this case, I had it silent for a while, and started sending music down to the base station – we can clearly see the FM in the spectrogram.


The handset to base transmission uses 39.775-40.000Mhz (10 channels) in Australia. In this case, we can see mostly echo coming from the handset and me clapping my hands twice. The separation in frequency is quite wide, which eases costs due to the use of less “steep” filtering to separate the receive and transmit paths.

With this, it is clear to see there is no privacy whatsoever in these types of analog cordless phones. Anyone within a few hundred meters with a good antenna and a good scanner is likely able to hear your conversations. The actual level of security offered is virtually zero.

Now you might be thinking – what is stopping me from using my neighbour’s line? It turns out that there is digital in the analog cordless set – that limited to the line-control and security functions.


When putting the phone onto the base, after a few seconds, the base sends a “code” to the handset, likely some pseudorandom access code for future commands to be encrypted with. This code persists until the next time the handset is placed into the base – so the system relies on having the handset replaced into the main base periodically to randomize the code and possibly avoid replay attacks.


When picking up, hanging up or sending DTMF codes, the cordless phone sends an FSK data stream (with quite a bit of chirp it seems) which contains the necessary commands for the base. In this case, I picked up and hung up the line in quick sequence. While theoretically, DTMF can be sent in-band, I believe that the cordless phone doesn’t do this to ensure the quality of the DTMF signals.


Any FSK commands are acknowledged with FSK signal on return from the base. The cordless seems to have a habit of resending commands for a few seconds until properly acknowledged to overcome variable channel conditions or until it times out and gives up. While this is probably secure enough, considering that each vendor has its own FSK signalling which is incompatible, it’s probably not resistant to attack.

Of course, worrying about this is a little silly when I’m also using a SIP VoIP service where none of the voice packets are encrypted and everyone along the transmission path can reassemble my calls. I wonder how “standard” SIP + RTP ended up in this very insecure state.


Of course, DECT is different, being purely-digital, wide-bandwidth, encrypted and channel “hopping” capable. It’s difficult to impossible to break into DECT, which is good peace of mind especially for AU$20. As it runs on a higher frequency of around 1.89Ghz, it means that smaller antennas can be employed, thus not needing the whip.

The analog handsets did have a channel button that was supposed to rescan and make the base choose a more suitable channel if there was congestion or bad signals. Unfortunately, it seemed to have quite the opposite effect, often causing dropped calls, or the handset to tune to a “empty” channel and play loud white noise.

I decided to compare new with old by using a VoIP based capture system and an ATA with two ports making two simultaneous calls to my desktop. The calls were synchronized and reassembled into this audio file where the left channel has the audio from the DECT 1015, and the right channel has the audio from the XSA660. We can see how the digital system is less prone to annoying white noise intrusions – but instead more pleasantly mutes. This is probably reliving the exact feeling of going from analog cell phones to digital cell phones in the mid 1990s.

The Need for Inbuilt Obsolescence?

The words inbuilt obsolescence normally conjures up conspiracy theory style thoughts of being forced to upgrade and being forced to spend more money. However, with technology, I think it’s been an interesting time to look at the whole forced obsolescence thing again especially with a lot of internet-of-things and embedded devices floating around the average home.

The problem really comes down to the fact that these devices are often only supported for a few years from their introduction, if the vendor is so nice enough to do so, and after that period has lapsed, they are forgotten. As security vulnerabilities are discovered almost constantly, there are many old routers and modems, printers and print servers, amongst other equipment that have critical security holes because they’re running older versions of Linux kernel, or they have older versions of certain servers running which are prone for exploitation. Inbuilt obsolescence seems to be a blessing in disguise for getting some of these devices off the network and away from causing more harm.

The problem really boils down to how best one might achieve this aim of taking old and vulnerable devices out of service before it is too late. The other issue also boils down to the threat versus the actual risk and danger – a critical IoT device at a home behind a NAT firewall with only a few trusted machines is not likely to endanger much – at most, it’s going to be the few machines on the network. The same device connected to a business network is potentially much more costly and dangerous. Ultimately, while many exploits have been “proven” to exist, the chances of having the exploit actually used against you may be acceptably small. Everyone has their own “timeline” for obsolescence.

In my case, I suspect that it wouldn’t have made much difference – I suspect not many people have even noticed analog cordless phones with their newfangled RTL-SDRs because they’re so rare to find in service, so I wouldn’t have been likely to have been intercepted. Likewise, we use the phone so rarely that the probability of intercept would have been low (probably more dangerous from the IP side). Further to that, it was providing acceptable levels of service. But the change to DECT gives me that peace of mind should a critical piece of information flow over the phone, that at least locally, information leakage is unlikely to occur, and I can enjoy slightly better voice quality and more consistent range.


I was well overdue to take my analog cordless phone out of service – it has now been replaced by a low-cost DECT handset for peace of mind. Analyzing the analog phone shows how basic the premise was, and how insecure it is, but on the whole, the risk posed was fairly low. Comparing the two side by side showed annoying white noise roars from the analog whereas the digital pleasantly muted here and there and was more clear.

It makes me wonder how best we should handle the need to take old technology out of service for security reasons …

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Audio, Tech Flashback, Telecommunications and tagged , , , , , , , . Bookmark the permalink.

6 Responses to Retired, Teardown: Uniden XSA660 Analog Cordless Phone

  1. rasz_pl says:

    dect has been cracked since 2008

    • lui_gough says:

      I was aware of this, although, I didn’t find it particularly encouraging.

      While some weaknesses are exploited, having the right hardware is difficult to come by, making the likelihood of attack quite a bit lower than with an analog set. MITM by impersonating bases and downgrading call encryption isn’t exactly uncommon – GSM had similar attacks, but I’m not sure modern DECT chipsets are vulnerable to this anymore. Weaknesses in authentication during connection are also documented, but I suspect the Uniden design is a little strange but also resistant to this because in order to actually accept/initiate a registration on the base requires the cradling of a handset to initiate the registration mode on the base. It’s problematic to join these handsets to other vendor DECT bases and vice versa due to this introduced incompatibility which may (on face value) make such authentication attacks more difficult to carry out. Finally, DSC hasn’t been broken aside from near-brute force searching (although offline with captured authentication packets makes it quite similar to WPA/WPA2) from what I could see, which means significant time investment or specialized hardware required.

      Needless to say, I do expect everything to have their own vulnerabilities – the actual risk really depends on how exploitable these vulnerabilities are, and how likely they are to be exploited. In the case of DECT, I still feel relatively safe because I don’t see the “average Joe” wielding a digital scanner and listening into every second phone call.

      – Gough

  2. matson says:

    What do you guess DIP refers to? (DIP and arrow on printed circuitboards)

    > Flash was probably … an endurance issue especially under heavy usage
    > or using a small chip with no wear levelling.

    I doubt endurance would have been a big issue. Here is my “napkin” estimation: over a operating life of 10-11 years (4000 days), five recordings every day, and five erase+program cycles to most heavily used blocks (index/log area) per record; comes out to one hundred thousand rewrites. From everything I’ve read, 100.000 cycles is not too much for NAND. (From that time-period, “just plain NAND” (today “SLC”) probably would have been used.) Please correct me if my impression is wrong.

    • lui_gough says:

      Dual inline package? Arrow points to pin 1? Else it’s to do with tin plating the board and the orientation it goes into the solder bath?

      I think it’s more so the wear levelling issue … old SLC was good (100,000 cycles or even more), but the cheaper MLC that they were more likely to employ was 10,000 cycles as far as I can remember. Without a good amount of logic to manage wear levelling (as primitive early music players didn’t), index areas get updated with each action – every call recording completed/deletion would cause the index to consume a cycle. Assuming 10,000 cycles available, and a single write update for delete, and a single write update for record, that works out to 5,000 recordings over the lifetime which at 5 recordings and deletions a day works out to be under 3 years. Modern MLC is worse … 500-3000 cycles is considered normal.

      Wear levelling would have made some difference, but required additional logic to spread out the cycles over the whole device – for non-wear levelling applications, if one particular index block fails, you’re likely looking at very strange device behaviour because it’s a “critical” file-system like area that holds information required to make sense of the rest of the device. It is also part of the reason some write-heavy applications were SRAM based as well.

      Which brings up another thought, maybe the reason is also to do with “speed” in a sense that flash has some “long” access times in erase of a block before rewrite and the data has to be substantially buffered. By using RAM which has a more “regular” access time and shorter cycle times, the buffer doesn’t have to be as big and that saves on cost as well.

      – Gough

  3. sparcie says:

    Interesting, I have a (now retired) analog cordless set that did something unusual. A couple of house moves ago I was using that cordless phone on a semi-regular basis to ring my parents. Every now and then it seemed another call would break in and I’d hear what I presume was someone else’s call. The funny thing was it sounded like one of those hot-lines for phone-sex. It generally lasted at most a few seconds after which the normal call returned leaving myself and my folks a little perplexed.

    In the case of the cordless phone, the newer technology is obviously better, but it’s not always the case. In fact using older technology that is little used anymore may end up being better in some cases as crackers lose familiarity with the old devices and they expect something different. Attacks like buffer over-run attacks require intimate knowledge of the hardware as well as the software, so using something a little obscure may defeat many automated attacks. Say something like using a MIPS or SPARC architecture instead of the more common ones (like ARM and x86). I believe the phrase is security through obscurity, I wouldn’t rely on it, but it makes cracking something harder.

    It’s interesting that many people assume Linux is behind most embedded devices, it’s certainly out there, but I thought that NetBSD and other BSD’s were more pervasive in the embedded market due to their permissive licensing.


    • lui_gough says:

      Very interesting. Depending on the band of the phone itself, it could have been a different band phone sharing analog frequencies with a wireless TV sender and you’re hearing the analog audio from it, or indeed, it could be due to a neighbouring analog cordless set.

      Because of the analog nature of the system, most sets (without companding and a pilot tone) cannot distinguish between signal and noise, and can only understand signal power. When you are moving around, chances are that your base signal becomes weaker than the interfering signal, and due to the FM nature of the transmission, the capture effect means that your cordless set begins to demodulate the interfering signal instead because they are “co-frequency”. When your signal becomes stronger than the interferer, the capture effect means that the FM demodulator goes back to demodulating the wanted signal (in basic terms, at least). The reason this may only happen for a few seconds is due to the nature of RF transmission and potentially due to multi-path. When you move around, or when other things which influence the reflection of RF move around, it can create dead spots where reflected waves cancel out with the transmitted direct waves causing null “weak spots”. With such analog sets, turning your head or moving a few 10s of centimeters either way can really make a mushy signal clear again.

      I agree, newer is not always better – security through obscurity is not a particularly strong form of defence, but I remember a case where a criminal stored his files on a Commodore 64 and that gave the police a good head-scratch! (

      As for open source – I’d still have to venture that Linux is generally more popular amongst consumer level embedded gear. I haven’t encountered many BSD kernels in embedded devices through poking in their firmware, but I suspect some higher end open-source based networking gear is likely to be BSD based. I suspect it may just boil down to packages, support and the laziness in porting things across, which leaves BSD falling behind in terms of userbase.

      Thanks for the comment, as always.

      – Gough

Error: Comment is Missing!