After a fairly long hiatus and a hard drive crash, I'm back at it working on this project. I am attempting to reverse engineer the remote control protocol in older Kenwood mobile radios. I'm using my TM241a but I understand that the RC-10 and RC-20 addons Kenwood used to make worked with a whole series of model numbers from TM-x21 through TM-x41 at least.
This was a secret from me until I found documentation and links talking about the RC10 and RC20 addons a year or two ago. I got my hands on operating manuals and service manuals for my radio, the RC-20 and the IF-20 addon. The IF-20 allowed you to connect up to 4 radios to a single RC-20. You could have 2,220,440 and 1.2 at your command if you were one of the lucky ones.
I've spent the last couple days poking around in the free Microsoft Visual Basic 2010 Express Edition writing a program to help me. My hardware interface consists of a Bus Pirate connected to the Mic plug on the radio using a spare plug I bought when working on a TNC project. I am running the Bus Pirate in transparent UART passthrough mode. Why not just use a usb-serial adapter? The Bus Pirate is already at the correct levels (TTL, not RS232) and I can program it to hold a pin HIGH, which is what the radio expects to enable it's remote control mode on the mic port.
Now, I can enter all of the Bus Pirate settings with a single button press on my program. I can read the display output continuously (though I still can't make sense of all of it yet). I can have a window with an active comparison going, output that is different is logged automatically. Right now, I'm running one of many routines to generate data and push it out the port. I'm trying to elicit a response from the radio by pretending to be an RC-20, or at least trying to guess what kinda of data one might send to it.
This would be unnecessary if I had access to either an RC-10 or RC-20, but alas they elude me. My fuzzing efforts are time consuming though. I've already ruled out 1 byte commands, sadly. That only took 255 guesses. I tried a 4 byte command guess with most of it filled in except for 3 nibbles. That took 4095 guesses. Nada. Now I'm sending 2 byte command strings, all guesses. That's 65535 guesses. Sadly, if I go up to 3 bytes then that's 16,777,215 combinations. Yes, almost 17 million!
BTW, I'm guessing about 40 times a second, so that's almost 30 minutes to run through 65535 guesses. 17 million isn't going to happen. There's a command for power on/off and transmit at least. Not to mention that while I was trying to figure out what protocol it used in the first place I accidentally entered junk data into it. Using the I2C address scan mode on my Bus Pirate somehow did it. That means there's a chance of a raw memory access mode. That could result in dangerous effects on my beloved radio, such as entering something that would cause the PLL to unlock permanently or TX at some weird frequency causing my finals to blow. I can't just let a fuzzing routine run all night while I'm asleep. A meltdown from excessive keydown is the least problem that could happen.
This is an example of the binary data the radio send out. It runs at 1200 baud 8,n,1 (ahh, bbs days)
00 82 22 A6 02 92 AA F1 40 42 02 12 02 22 01 E0 82 41 10 01 FF
The oddball part of this is that the bit order is reversed. ie 1100 would be 0011 actually.
If you reversed the bitorder and re-wrote the line:
00 14 44 56 04 94 55 F8 20 24 04 84 04 44 08 70 14 28 80 08 FF
The radio seems to use the first nibble for data, with the second nibble acting as some sort of checksum, or maybe even frame marker/address.
00 14 44 56 04 94 55 F8
0 1 4 5 0 9 5 F <- First nibbles only -- I'm on 145.095
0 4 4 6 4 4 5 8 <- Second nibbles only
Second nibbles of 0 and 8 seem to mark the beginning and end of subframes within the frame.
Second part of the frame from 20 through 08 seem to be fixed LCD elements (T +- BUSY etc)
70 - x8 are memory channels if you are in the MEM. This happens to be Memory Ch 12 for me.
70 14 28
7 1 2 <- ch 12.. Channels under 10 are 7 F x (where x is the channel #) so 7 F 9 is Ch. 09
0 4 8
...If I remember right, if you are in VFO or Call the Mem info is different, or missing entirely. That was in my notes that were lost forever in my hard drive crash a little while back.
80 08 are currently unknown for me.
00 and FF always mark the beginning and end of one whole frame.
Once you get the radio started, and all you need to do is send 1 byte of any sort at the right speed to it, then it continually sends display frames out at 1200 baud.
If you receive a signal, the S-meter data is sent out as well, in the form of setting one of the bits in the LCD element section and 2 additional bytes before the 80 08 pattern. It seems to have a hold pattern, if it's not changing then the radio stops sending the extra 2 bytes until it does change and then the radio will send out the changes again. I believe they resolve into the number of S-meter bargraph elements that should be lit up.
I'll keep plucking away at it. I do love a puzzle.
This was a secret from me until I found documentation and links talking about the RC10 and RC20 addons a year or two ago. I got my hands on operating manuals and service manuals for my radio, the RC-20 and the IF-20 addon. The IF-20 allowed you to connect up to 4 radios to a single RC-20. You could have 2,220,440 and 1.2 at your command if you were one of the lucky ones.
I've spent the last couple days poking around in the free Microsoft Visual Basic 2010 Express Edition writing a program to help me. My hardware interface consists of a Bus Pirate connected to the Mic plug on the radio using a spare plug I bought when working on a TNC project. I am running the Bus Pirate in transparent UART passthrough mode. Why not just use a usb-serial adapter? The Bus Pirate is already at the correct levels (TTL, not RS232) and I can program it to hold a pin HIGH, which is what the radio expects to enable it's remote control mode on the mic port.
Now, I can enter all of the Bus Pirate settings with a single button press on my program. I can read the display output continuously (though I still can't make sense of all of it yet). I can have a window with an active comparison going, output that is different is logged automatically. Right now, I'm running one of many routines to generate data and push it out the port. I'm trying to elicit a response from the radio by pretending to be an RC-20, or at least trying to guess what kinda of data one might send to it.
This would be unnecessary if I had access to either an RC-10 or RC-20, but alas they elude me. My fuzzing efforts are time consuming though. I've already ruled out 1 byte commands, sadly. That only took 255 guesses. I tried a 4 byte command guess with most of it filled in except for 3 nibbles. That took 4095 guesses. Nada. Now I'm sending 2 byte command strings, all guesses. That's 65535 guesses. Sadly, if I go up to 3 bytes then that's 16,777,215 combinations. Yes, almost 17 million!
BTW, I'm guessing about 40 times a second, so that's almost 30 minutes to run through 65535 guesses. 17 million isn't going to happen. There's a command for power on/off and transmit at least. Not to mention that while I was trying to figure out what protocol it used in the first place I accidentally entered junk data into it. Using the I2C address scan mode on my Bus Pirate somehow did it. That means there's a chance of a raw memory access mode. That could result in dangerous effects on my beloved radio, such as entering something that would cause the PLL to unlock permanently or TX at some weird frequency causing my finals to blow. I can't just let a fuzzing routine run all night while I'm asleep. A meltdown from excessive keydown is the least problem that could happen.
This is an example of the binary data the radio send out. It runs at 1200 baud 8,n,1 (ahh, bbs days)
00 82 22 A6 02 92 AA F1 40 42 02 12 02 22 01 E0 82 41 10 01 FF
The oddball part of this is that the bit order is reversed. ie 1100 would be 0011 actually.
If you reversed the bitorder and re-wrote the line:
00 14 44 56 04 94 55 F8 20 24 04 84 04 44 08 70 14 28 80 08 FF
The radio seems to use the first nibble for data, with the second nibble acting as some sort of checksum, or maybe even frame marker/address.
00 14 44 56 04 94 55 F8
0 1 4 5 0 9 5 F <- First nibbles only -- I'm on 145.095
0 4 4 6 4 4 5 8 <- Second nibbles only
Second nibbles of 0 and 8 seem to mark the beginning and end of subframes within the frame.
Second part of the frame from 20 through 08 seem to be fixed LCD elements (T +- BUSY etc)
70 - x8 are memory channels if you are in the MEM. This happens to be Memory Ch 12 for me.
70 14 28
7 1 2 <- ch 12.. Channels under 10 are 7 F x (where x is the channel #) so 7 F 9 is Ch. 09
0 4 8
...If I remember right, if you are in VFO or Call the Mem info is different, or missing entirely. That was in my notes that were lost forever in my hard drive crash a little while back.
80 08 are currently unknown for me.
00 and FF always mark the beginning and end of one whole frame.
Once you get the radio started, and all you need to do is send 1 byte of any sort at the right speed to it, then it continually sends display frames out at 1200 baud.
If you receive a signal, the S-meter data is sent out as well, in the form of setting one of the bits in the LCD element section and 2 additional bytes before the 80 08 pattern. It seems to have a hold pattern, if it's not changing then the radio stops sending the extra 2 bytes until it does change and then the radio will send out the changes again. I believe they resolve into the number of S-meter bargraph elements that should be lit up.
I'll keep plucking away at it. I do love a puzzle.
