This weekend, Interlock participated in two milestone events: Our third annual meeting, which we’ll talk about in another post, and one of our members getting married. Walter (N2VBP) and Cheryl have finally tied the knot to make it official.
Attendees were friends and family of the couple including Walter ‘s daughters who he setup on Skype to stream the wedding live. Our resident video podcaster Radical Geek recorded the ceremony and I, with my newly acquired credentials from the Universal Life Church Monastery that I signed up for on the Internet, solemnized the wedding.
Brian, also decided to do a 3D sculpture of the Walter and Cheryl so he took a bunch of pictures as they held hands. With the help of some software, he’ll be able to turn them into a 3D model and hopefully print them out so they look like cake toppers. Congratulations guys!
This Tuesday at 7pm, we’ll be welcoming Rob Bishop of the Raspberry Pi Foundation to do a workshop. He’ll be bringing in a bunch of Raspberry Pi’s to play with and hack on during the event. The workshop is, as always, open to the public so we welcome anyone that’s interested in attending. This would be a good time to either start learning about Raspberry Pi’s or take your project to the next level.
A project that I’ve been spending a lot of time on, is learning about how this silly little RF remote communicates to its home base. The remote controls a music playing device and since it’s RF, the project required me to learn about radio frequencies and some hardware hacking. I’ve been asking Interlock members for help and they’ve given me ideas along the way. JustBill, one of our radio hackers, has jumped on the project and started analyzing the remote from the RF perspective. Berticus and Robo Alex have also donated their brains for the hardware hacking portion. Our goal was to learn how the remote works so that we can make our own remote.
This radio frequency remote control (RF RC) controls a device that plays music. For the purpose of this post, that’s all we need to care about it. Our first step was to do recon on the hardware so we researched the FCC documents. Taking it apart we learn that there are two boards we want to worry about. The remote board that has an integrated circuit (IC) to handle button presses, and a radio daughter board that takes input and converts it to a a radio signal.
After taking apart the remote, we look at the lower portion to find an IC made by Hynix. Thankfully, Hynix still sells a similar chip that’s designed for infra-red (IR) and was nice enough to give the pin outs in the data sheet that looks like this:
This tells us most of what we want to know to see what happens during a button press. We verify this with a Salae Logic Analyzer that I love a lot, and we can make this block diagram.
The logic analyzer also gave us a good quality sample of what the signal looks like before it is sent to the RF daughter board. In the diagram above, if you look at the thicker line, this represents the communication going from the Hynix chip, to the RF daughter board. And that signal looks like this:
What’s interesting about this is if you look at it closely, it’s has 32 transitions from digital HIGH to digital LOW during a single transmission. If you split them up into bytes, we now see 4 groups of data being transmitted. The first group is the sync to tell the device to listen and is always “0 1011101.” The second is a PIN that can be set to make sure the remote only talks to this device and not other ones. Basically, this is a passcode that can be anywhere from 000 to 255. The third group is the button ID. This tells which button is being pressed. The last group is a verification of the button ID which is done by doing a bit flip of the previous binary. “00000001″ turns into “11111110.” So I created a map of the useful button IDs for later: Power is decimal 30, volume up is 79, pause is 76, and mysterious “P1″ is 14. So if we wanted to transmit a power button with a pin code of “000″ it would look like this:
01011101 00000000 01111000 10000111
One of the reasons this project became fun was because the radio doesn’t transmit on IR. It’s RF only. This means that all the amateur radio operators at Interlock could come to my rescue and explain what was going on. First we needed to find out what carrier frequency it used. It turns out that we didn’t have to look to far because both the carrier frequency and the modulation type were in the remote’s owners manual!
In this case 433.92MHz FSK are for new versions of this device and 27.145MHz are for older. 433.92MHz is in the ISM band and used by a lot of small electronics like a garage door opener. Our first goal was to capture a sample of the RF so that we could analyze the data in some kind of FFT. This would tell us the data inside of the transmission as well as confirm which type of encoding it was using. (FSK, ASK, PSK, etc)
The first attempts to use ham radio equipment were a failure. We later found out that the equipment could listen on 433.92MHz, but the ham equipment was listening on too narrow of a bandwidth to correctly capture the entire signal. The company I work for was happy to lend me their USRP. Yay!
If you’ve never heard of a USRP, this is what ham guys normally call a software defined radio, or a radio that can be a range of frequencies depending on what you program it to be. You can control things like bandwidth and frequency by sending it a simple command. The USRP was designed by Ettus Labs and sold to National Instruments and has become a defacto part of the RF hackers’ toolkit.
With this, we were able to get a good sampling of the transmission from the remote that looked like this:
Putting the RF signal and the data collected from the logic analyzer, we can now make some conclusions. Namely, that this is an extremely simple circuit that isn’t doing much encoding or modulation when its being converted to RF. Basically the RF signal that you see above, is the exact same as the data being sent by the Hynix chip. This will be important later.
To review we have:
reversed the hardware that handles pressing the button
captured a sample of the RF signal
discovered what data is being transmitted and how
The next step was to create my own remote from scratch. I did this using an Arduino and an RF chip designed to transmit on 433.92MHz. Thanks to Robo Alex for setting this thing up for me. It turns out I don’t need the ground plane which is that giant piece of copper in the picture, but it doesn’t hurt.
What this does right now, is transmit on 433.92MHz, whatever button that I’d like, supplying whatever PIN code that I’d like. When I capture the data using the USRP, I find that my Arduino kit transmits perfectly at 433.92MHz while the remote has an offset of about 60 hertz so that it transmits at 433.98Mhz. That’s kind of a deal breaker for me right now and I’m looking for a replacement IC or something else so that I can transmit on the correct carrier freq. Until then, enjoy this random data.
If you want to hear more about this (I don’t know why you would), JustBill and I will be presenting this information (and some other things) at Defcon‘s Skytalks next week. If you’re going to be in Vegas for Defcon/Blackhat, look me up. For more information, follow me on twitter.
Saturday May 12th is the second annual BSidesROC hacker con. It’s Rochester’s only “Hacker con” and Interlock will be there running a booth and showing support. Come visit our table.
What to expect
If you’ve never been to a hacker con, it’s a bit different than your standard conference. Don’t expect the venue to be a hotel. In fact, it’ll be at an old Masonic Temple inside the Auditorium Center.
There will be a lock picking village where the local Rochester TOOOL chapter will be around to teach people how to pick locks and the issues involved with physical security. They’ll also be selling lock picks to attendees.
Other stuff for those interested:
a dozen or so presentations about information security by industry professionals