Interlock is a non-profit organization that provides space for its members and the local community to develop and share their interests in science, technology, art, and culture.
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.
RF RC
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.
IR IC
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
RF RF
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:
Signal Processing
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.
Results
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.
Defcon
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.
We’ve held the second of our monthly 3D printing meetings recently, with a fifth person getting trained up on how to use our current printer, and are on the cusp of another advancement in our previously-mentioned 3D printing capabilities, now that 3 people have decided which printer design they’re going to build next.
In the meantime, we continue to torture Beardicus’s poor little Huxley RepRapPro making other little tschotskes that speak to our interests. This doesn’t get us closer to the glorious future of 3D printers for everyone, but I like to think of it as our answer to Wall Street’s “profit taking”: Every once in a while it’s nice to just cash out a little bit and enjoy what you’ve already got.
My turn at that most recently was this little model of monomeric insulin, based on the crystal structure reported by Gursky et. al.
The trick is how to take a computer model of something like this:
and print it on the 3D printer so that it goes from being an on-the-screen abstraction to something you can hold.
I’ve been getting into twisty puzzles recently. Mainly Rubik’s cubes, as well as cubes and puzzles by other companies and designers like WitEden, Mefferts, TomZ, and so on. While looking around, I noticed a few designers are printing one-offs via Shapeways, and other designers are offering their puzzles through Thingiverse. I’ve been wanting to make a 1x2x3 puzzle for a while, probably making one my own from spare parts, but I happened to see a couple of 1x2x3 designs available on Thingiverse…
Very shortly after Brian, Alex, and Bill got Interlock’s 3D printer going, I nudged my way in, and got them to print out a twisty puzzle for me. The puzzle I had printed was this screwless 1x2x3 model.
I decided to go for this one becuase I wanted to have it printed out and ready to go as qucickly as possible. In retrospect, I should have gone for TomZ’s 1x2x3 design, for reasons I’ll get to later. Anyway… on to the printing!
The printer did a great job of producing the pieces, although it would seem that perhaps the filament was being fed into the printer too quickly, as tolerances were overshot, and much sanding needed to be performed just to get it to fit together…
This design included a “barbell” shaped piece that snapped between the two halves of the core, eliminating the need for screws and springs to hold it together and give it tension. Because of the lack of support material, the printer had a difficult time properly printing out this barbell, as you can see in the following picture. There was nothing to hold it in place, so it got dragged around a bit as the print head moved around.
The next step I took was to sand down the parts to get them to fit. The first thing I tried was sanding the ‘feet’ that protrude from the wing pieces. I was getting decent results, but then realized that a better solution was to sand the semicircular holes in the cores a bit more, opening them up, making the feet spin in the core more easily.
Between various nights of heading to Interlock to work on this, and without the needed barbell piece, I held it together with a rubber band.
Next, Joe came to my rescue. He extracted the barbell piece out of the STL file, sliced it in half, then printed those two halves for me. This time using the stylish metallic gray filament, rather than the stylish orange filament.
A little bit of super glue, and a little bit of sanding, and they were ready to install inside of the twisty puzzle’s core. Within minutes, it was assembled properly for the first time! The barbell/snap assembly is a bit loose, and I think that some of the feet were sanded down a little too much, as there is a lot of play in the fit of the parts.
I was planning on perhaps dyeing it, or just sanding more and stickering it with the expected color scheme (red, orange, green, blue, white, yellow) but Nick had asked me a little about rotational symmetry of the puzzle, and a few minutes later, he had stickered it with blue painter’s tape. It was an ingenious solution, as no two pieces are stickered with the same pattern. (Note that you can also see the floppy tolerances on the top left piece of the next photo.)
After playing with it for a while, the barbell is definitely the weak point of the whole thing. I had sanded it a little to get it to turn more smoothly, but now it’s way too loose. The wing pieces are a bit floppy due to sanding. I think that these two things can easily be changed for the next print, by first using TomZ’s design which can use a screw to hold it together, and also being more cautious while sanding to keep everything within decent tolerances.
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
Every month, on the 4th Thursday of the month, we host a meetup for anyone interested in 3D printing. Come see what all the buzz is about and maybe print your own thing from thingaverse.
For more information, follow me on twitter.
0 Comments
