Hacking FRS radios (walkie talkies)

Back in the early 90s, I got an 8 channel desktop scanner (radio receiver) on clearance at Radio Shack for about 20 bucks. The thing was real basic, with just a 7 segment LED display, no search capability and only 8 channels of "memory". I quickly got bored with just using it and decided to crack it open to see what made it tick. I was able to identify the microcontroller and another IC that I assumed was the PLL tuner. At the time, I didn't know much about PLLs and couldn't find the datasheet for the one in that radio, so I found one that was similar in function in a Motorola databook. After reading the datasheet and an appnote, I got to probing around on the radio. Long story short, I cut the traces between the PLL and the microcontroller and diverted the PLLs serial and other control lines to a 25 pin connector so it could interface with a PC via the printer port. I wrote a DOS based C program to control it and wound up with a 200 channel (about what I could fit on a 43 column VGA text screen) scanner with an automated, active frequency search function. That was a very educational 2 or 3 weeks I spent on it.

With my interest in amateur radio ramping back up recently, I decided to buy a pair of FRS/GMRS radios to check their ease of hacking for Ham use. FRS frequencies are very close to the amateur radio 70 cm band and I figured "all that's needed" is to tweak the frequencies a bit to be able to operate a really cheap transceiver for ham use. I bought a pair of Cobra brand MicroTalk model radios for $40. Before even powering them up, I took one apart to check the guts. Oh, then I googled "hack microtalk" and found this blog post. Not much active info or progress there, though.

When I dug into the MicroTalk radio I found the highly integrated AN29160AA transceiver IC from Matsushita (a different, Uniden radio is shown below which uses a AN29160A variant).



This chip does about everything except drive the display and handle the pushbutton inputs. Its functions, the PLL counters/divisors that set the tuning frequency as well as volume control and more, are operated by an external microcontroller through a 3 wire serial interface. My obstacles in attacking the MicroTalk radio were the very fine pitch surface mount leads and the fact that its microcontroller is hidden under the LCD display assembly. Not impossible to deal with, but tricky.

It occurred to me to check an older pair of Uniden brand FRS radios (model GMR638-2CK) that I already had. They actually turned out to not only use the same transceiver IC, but (in my opinion) to be a bit easier to hack. In this radio, the microcontroller was not buried under other stuff and even has handy little test point pads for every pin!


As you can see in the picture above, I've identified the basic signals that I need to hijack from the microcontroller. I may also need to monitor the squelch logic output and possibly provide an analog signal to generate tones. The earlier picture of the transceiver IC is also from the Uniden radio. Below is an o-scope snapshot of the DATA line being used while the radio was scanning FRS channels:



So far I've identified some necessary signals and the means to calculate the PLL counter values for arbitrary frequencies. Next I must plan what microcontroller I'll use to operate this thing, along with which other signals between the 29160 and the existing micro that must be hijacked or just piggyback onto. I also need to figure a clean way to put it all back together so that it can still be a handheld!

I may use Cypress Semiconductor's First Touch kit as the controller. It's a PSoC and probably way overkill, but for a few points: it's small, has all the IO I need and... I have one!

Check back later for more progress.

Overhead door sensor

A couple of months ago, one of my two garage door openers stopped cooperating. It acted like the light sensor/source pair that are supposed to detect when something or someone is in harm's way weren't working. The green LED on the sensor module wouldn't come on. So, after some weeks of ignoring the problem, I started digging into it.

First I opened up what turned out to be the source module - the one that provides the infrared light "beam" for the sensor to pick up. Not visible signs of problems there. Then I opened up the other one, the sensor module. After a few minutes of tracing out the circuit, I ran across the obvious. Can you spot it (click the pic to expand it)?



In case you missed it, there's a pin near the upper left corner of the board that isn't soldered in. That is the collector pin on a transistor. Pretty important connection to be made in most circuits. I guess this one was bent over far enough that it was contacting the pad on the PCB and had worked that way for untold years. ICs on various boards in the system have batch numbers from late 1997, the house was built in 1998 so the silly thing may have been working for as many as 12 or 13 years with this flaw. I figure either I, the cat or the kids wacked into it one time too many and jostled that delicate connection loose. Anyway, after a bout with the soldering iron, I put it back together and it works fine again.

This experience was similar to another one recently when the blower fan for the air handler in the central heat and air system stopped running. In that case, the fan control PCB's faulty connection *had* been soldered in, but the pad on the PCB apparently was not designed to handle the current. Over time, it melted away the solder first, then arced away at the remnants of the pad until it finally had nothing to arc to. Soldering a piece of 14 AWG wire across the right points took care of that one.

Funny thing, there - I knew exactly what to look for because precisely the same thing had happened at the "old house" a couple of years earlier. Took me about an hour the find and fix the first time and only 15 minutes the second time.

Cable ISPs

Incited by the topic of my previous post, I did a little hunting. The cable ISP I use at home bought a big chunk of their network, including that in my town, from the "upstream" ISP I mentioned earlier. I did a wee ping scan and found that I've been quite naive with respect to cable ISP security.

I discovered that at this ISP (and there's a bit of assumption here) all of the cable modems get a private IP in the 10/8 range in addition to the public and routable "WAN" IP that gets assigned to it. The unhappy part of this is that my cable modem's status web interface is available to anyone on my "local" ISP's network. If I thought about it all, previously, I guess I assumed that the CM's web interface was only local and not exposed to a fair chunk of the Net. Some cable modems only show their connection status, others provide a management login prompt... I imagine that many of them are still set to accept the manufacturers default password. This is on a network with potentially thousands of "local" users. The potential problems compound for those modems that double as wireless routers, such as mine. Once authenticated on it, one can navigate to a page that reveals the pre-shared key that is necessary to get past the WPA encryption on the WiFi side.

In case you want something to take home from this topic... if you have a cable ISP, lock down your modem by changing its default password. It may sound silly and simple, but while totally unsecured wireless routers are vulnerable to anyone who's out wardriving, your cable modem may be open to any basement dweller on your same ISP (or siphoning off a cable subscriber's WiFi).

"So?" you say. "At least the cable ISPs are limited in geographic and IP routing scope, so how much damage could be done?" Consider that pretty much *every* ISP currently has multiple subscribers whose computers are already infected with malware and may be part of a botnet. How much more difficult would it be for the bad guys to leverage an existing malware presence on your local cable ISP to wreak more harm? Plenty of room for clever, evil mischief.

Gotta keep'm separated

Ran into an oddball network issue where an ISP and their upstream are routing private IPs in the range 172.16/12. They aren't advertising bogons to the world at large (I checked), but quietly routing private IPs that appear to comprise a portion of the upstream's management network.

My local environment is two LANs, one on 10.0.0/8, NAT'd to the public Internet and the other on 172.16.0/12 with all manner of Linux and embedded devices hangin' on it. There's a Windows machine that straddles the networks using 2 separate NICs. A cohort noticed the problem at the Windows box when he tried to telnet to a device of his on the 172.16 LAN and got a login prompt for an ADVA Optical Networking device somewhere in the Outernet instead. A traceroute quickly comfirmed that he wasn't going nuts. I guess it ain't up to me to tell an ISP that it's bad mojo to expose their network management nodes to their customers (downstream ISP) and *their* customers (me), but hey, this is mucking with my network! 172.16 is private and I should be able to use any part of it without fear of colliding with someone else's IPs anywhere out on The Internet.

I emailed the NOC POCs of both networks and got responses, so they'll probably work something out. In the meantime, I needed a way to corral my own two networks and keep'm separated. The Windows 'route' command seemed to fit the bill. It ain't exactly like the Linux route command, but with a little reading and testing, I came up with this:

1) Get a command prompt

2) > route PRINT

3) find the numbers (left column) of the interfaces on the main (outside) LAN and the development (inside) LAN

4) Restrict main LAN interface to 10/8:

> route ADD 10.0.0.0 MASK 255.0.0.0 10.0.0.1 METRIC 1 IF [main LAN interface#]

5) Restrict development LAN to 176.16/12:

> route ADD 172.16.0.0 MASK 255.240.0.0 0.0.0.0 METRIC 1 IF [development LAN interface#]

That seemed to do the trick.


So, problem averted but not really solved. How common is it for ISPs, small or large, to route private IP space within their networks and even between their peers and downstream networks?