 Hello. Yeah, I'm here. I'm Peter Shippley. And we're here to talk about Insteon. I like giving out lines for talk. This talk is a little bit backwards in a sense. I see a lot of talks at various conferences where they talk about the research, talk about what they're doing and not basically hold the good stuff at the very end like a mystery novel. Talks are not supposed to be a mystery novel. So I plan to go over things. I'm going to give you the conclusion. I'm going to talk about how I got there. Those of you within Insteon, it's a wireless protocol. A bunch of devices like this, plug around your house, get a home controller, turn lights on and off, activate sprinkler systems. I got bored, I set my house up with it and started playing with it. Technology is run by a company called Smart Home. They control devices that do either wireless or RFR protocols. Some called dual band communication, which actually is an asset and a problem, as we'll soon see. All the bases are capable of acting as a repeater. So effectively any lights which are in your house are also a radio frequency repeater. It's really easy to pick up their signals. Now, what are they good for? Well, they're paired with Google's Nest and they've also paired with Microsoft's and they have little plugins for that. I've not actually seen it yet, but this is why it's relevant. Insteon is, you know, Insteon by itself is not a security problem unless you actually hook up your locks. But they're being paired up with more and more automation. Automation has become more and more of a product. This is the weakest link. And I may give you this talk so the weakest link doesn't become part of the chain. Things you can do with it. No, I'm not trying to sell you the product here. You turn your lights on or off, control your sprinklers remotely if you wish. Locks, interface directly into alcohol arm systems. You have IO controllers so you can manage water pumps, all time road sensors, all these little things. As I mentioned about the weakest link, well, it's a protocol for light and environment. It's being integrated into many, many other things. And this is a problem. Yeah. For example, we have a lock on stage here. With this and RFCAT, I think you can open that lock. Hopefully we'll do that a little bit later. By the way, I'd like to point out here, just to be fair, with Moisture locks, the lock is a good lock. It's not Medeco, but it's an upright state lock. And the remote control is a rolling key code. So the Moisture product is pretty good. The weakness is the Insteon bridge to it. Now for those familiar with Insteon, you might have read their papers. They actually published specifications on their RF protocol. By paper you could just Google white paper and the details will get owned. This has been published for about 12, 13 years so far. The protocol has not changed. It's been heavily documented, heavy detail for the last decade or so. This is a problem. They also have a very biased documentation compared themselves to other wireless protocols. You can read that if you want, but you don't really need to. Yeah. Well, three of the specs, a bit of a hacker, I decided, you know, I can invent the RFCAT. I'm a pretty good programmer. I've been doing, you know, C program for 20 years. And so I wrote code to do it. My code didn't work, failed spectacularly. Normally my code doesn't fail that bad. Just a little bit. And this is interesting. I mean, they tried to get the packets before the protocol. I was getting nothing. So I investigated. I successfully reverse-engineered the protocol. It took me a while. A lot of my friends got annoyed with me talking about it. Their protocol documentation is so full of shit. They ran out of ways of saying bullshit in my documentation. Okay. One of my things I could do, that would be a lot of space operas in my Kindle. I have space operas that contain less fiction than the protocol documentation. Forcing bullshit by friends of multiple little friends. Let's get on to the fun part here. Let's talk about the protocol that we were talking about. You know, together with the stuff. Well, this is what they claim to be the protocol. How accurate do you think this is? Frequency, bullshit. It's actually pretty close. It's off by a couple of cable, just enough to make your demodulation a pain in the ass. Manchester coding, bullshit. Quase express in Manchester followed by two ones. You can't decode it with Manchester. Believe it or not, they actually use frequency shift modulation. Bullshit. Bullshit. Bullshit. A 3% bullshit. Insan describes frequency shift key as the symbols that are modulated using frequency shift key and blah, blah, blah, blah, this character. Bullshit and cling on. If you want to be more accurate, the frequency of the deviation, actually back up there a little bit. They claim that the modules use center character frequency shift by one symbol. They actually got that little bit wrong. Deviation is a shift to the center frequency to the 100, not the entire thing. So basically they got that wrong. Bullshit. So let's just say this is a typo. We're going to be nice to them. Just clarify things. If you read the documentation, which I don't fully quote here, they're very, very, very clear to say the full shift is 64K. It's 150K. Now, on that point, what the actual spec is, as you can see, this is the real spec. Real frequency is a little bit off, tokenized Manchester. I love how they claim to be a little over 3,000 data rate. It's more like 2,600K. The symbol rate, not even close. Now, let's pack some more. Look at the standard packet format. This is the standard packet that you'd expect to see something transmitted. Who here thinks that's accurate? Come on. Aguache. The extended packet. Malarkey. Not even close. This is the actual packet order. Back up a little bit here. You can see that they talk about is a preamble, a sync from address to address flag. Where in reality, it's actually the flag to address from address. So the byte order they give it to is even wrong. It gets worse. They claim the order by byte. This is actually head-by-head pounded on the wall for quite a while. It's figuring out how the bits are encoded here. I lived and wrote a program called Xort, which, since I knew the MAC address of all my devices, I figured it's an encryption would be that hard. So I wrote a program that takes my MAC addresses, shifts them, reverses them, inverts it, and Xort is every possible combination of my MAC address against the packet. I was getting lots of hits. Someone pointed out I could feed Gideon's Bible into the program. I would get lots of hits. So I went back, analyzed it some more. There's actually things that actually work. That's the laser. The laser is missing. The laser is ready. Two points off of me as a speaker for not being ready. I can't even see my own screens. So effectively this is how it's encoded. Here's three bytes. Don't worry about the figure now. Effectively the three bytes, everybody is actually encoded with... Back up one. Okay. So we're just going to look at how three bytes are encoded. The first three bytes are your O3, E5. The packet is actually set with a five-bit index number followed by the eight bits. It's transmitted least significantly bit first, so we flip that whole thing over. And then Manchester encoded. It can make your life just wonderful. And actually the lines at the top, that's actually a raw dump of the whole thing. It's only three bytes of packets. It's a very, very inefficient method of transmitting this stuff. Well, somewhat. It's not like Manchester is two to one. It's like three and a half to something. And the data effectively, the packets, flags, right, this is actually from the documentation and it's actually correct, believe it or not. Shocking. I think it's the only thing in the documentation that was accurate. Instagram also talks about their message binary. They have a CNC. After researching this, it took me quite a while to figure this out. And it's complete poppycock. It's not a linear shift register. The actual documentation, which by the way, the second half was talking about how I actually cracked the CRC, which is a pretty good interesting thing. Basically it's not even interesting. They basically shake the XOR, shift the upper nibble. I tried describing this and I tried actually working this slide out. You can actually read what I'm talking about. It's just easy to say this. And yes, this will all be published and I have a website with this. Now for the fun part. Instagram claims to be secure. The security to quote them, if I want to read my own slides here, is maintained by two levels of security. A lean control system where users cannot create links without physical access to devices. And basically you need to have possession of physical vice. Then two or three pages later, the documentation that talked about software pairing, we know the MAC address that you can use. So I'm not going to try to pronounce that. My Russian friends say it's garbage. Again, these are quotes from the actual documentation here. To keep things secure, the firmware prohibits you from reading devices you're not paired with. Who here trusts firmware to protect your secrets? Yeah. Exactly. They claim they masked the high bytes of all traffic. Did I mention the RF protocol a few minutes ago? Do you think it might be a little problem with the security here? Yeah. Now, Instagram relies on basically that they have a three-byte unique address. They call it node addresses. I call it MAC addresses. It's easier to think that way. And they all encrypt with basically unencrypted. So there is no security. They actually publish an entire white paper describing their security versus ZigBee which actually is an encrypted protocol best. Another multiple thing that really annoyed me with Instagram documentation is their claim of encryption. If you're a security person with a sharp eye, you'll spot this. But a lot of my friends who I think are pretty good, miss this one. They claim that they support encryption in instead of messages. This is not quite true. They support encryption just as much as any other layer 2 protocol does. You can pass a packet that is encrypted. White sheet of paper has just as much cryptography as Instagram. And if you read the between the lines here, they say, their extended packets can contain encrypted payloads. It's not say they're actually encrypted. You tell who speaks what language or who last while you take the slides here. They actually quote from them extended messages allow for encryption of AES-256. I think they said that because ZigBee uses a lesser one. They do not support encryption. Instagram does not directly encrypt anything. You go through all the documentation and they mention they're encrypted about every chapter. Bullshit. I've never seen a company lie so heavily about their documentation. And it would be so clear text and transmission. Let's get to the more technical stuff here. I've picked on Instagram enough. How about reverse engineering? In this talk I was going to say something in the effect of how I crack the protocol. Everybody here has been to an SDR talk about two per year of how to crack a radio. Go with IP or something like that. Those guys are as good a job as I would at documenting how to reverse our protocol. I will talk about is a checksum. When I need to crack the checksum for this thing, it took me a while. There wasn't a good documentation on it. I read a lot of academic papers talking to me about how to crack a CRC. So I figured I thought of my slides to explain to you how you're going to crack a CRC if you ever need to. Not that hard when to figure it out. Their documentation claims have a sub-bit linear shift register. Bullshit. So I look into this. Four should be dealing with eight bits. Here's an example of some actual packets. If you bring the packets together, if I XOR the packets, the whole side is the XOR equates to. If you notice the first one, it always ends in zero. That tells me that the second nibble or the lower nibble is a simple XOR. The upper nibble is not. I found a little bit how to crack the whole thing. Next week we want to crack a CRC what we want it to do. We'll look at the higher nibble. Because it generates packets, it generates 255 packets, 255 values, I was able to generate packets of various information. What I did was since all these packets varied by what bit, I simply XORed the packets together. The resulting data is only the changed bits. What you see here is the packets XORed with themselves. They only see the bits that have changed. Again, as you see here, strange enough, the upper nibble doesn't affect anything. So it's obviously not sub-bit linear shift. Next thing you do is vary your packet identity. With this, I was able to derive the formula. Again, this is how you crack an 8-bit CRC. In this case, it makes it easier to read or replace these zeros with dots because I see it. From here, you can clearly see how the algorithm works. A little bit clearer might be this. In this case, the algorithm is very simple. You take the first nibble, shift by one, XOR over the self, apply it to the upper hand. You can see it's improving. They lied. Again, that's a nice protocol. Aside from the standard procedure identifying RF signals, like I said, I'm not going to waste your time with that one. I've written tools for this. I hope it's somewhat useful. We have a handful of tools designed to be modular and reusable. I tried to base my tools off of standard hardware. Standard hardware being using standard hardware. I have a new modulator for this. Here's an example of commands. I'll basically read and decode live streams of the data. With those live streams, you can play, replay, and attack systems. To transmit any packet, same thing. After this, you can give demonstrations some of the software. After that, we'll have some questions to answer. Tough crowd. Hopefully, some of this will work. Likely. None of it will. But we'll see. Another one to do the command. Yeah, I'm trying to get to it. All right. No video. Awesome. Okay, cool. Yeah. So, first thing we have going here is the lovely little RF cat dongle. You may notice this one is soldered and hot glued. That's bait's fault. So, very simply, we've got a couple scripts here. One's going to receive data from the RF cat, and then output it to the screen, showing you what the packets actually look like once they are sane. About this. So, if you'll notice here, I have a very sane device that is a light switch attached to a power plug. So if you may think this is insane, but it's also a transmitter, so if I hit up and down, you'll see I start getting packets. So, the 11, 78, 28 here is, I believe one of the lights that we do not have hooked up, because we could not find a lamp. And the other ideas are various things that this is synced to. So, if you want to turn on lights in Shipley's house, please take a screenshot of this and the tools we posted after the talk. Just a piece of field in here. We've got the flags here, which is the only thing that was correctly documented in the protocol. You've got your from address. Your to address. And it's interesting, because in the documentation, they talk about how it's supposed to go to the from address transmitted first. The reason that's not done is due to the way the pairing works. So, theoretically, you only talk to devices that you're paired with. So you're actually more concerned about your from address than your to address when you're dealing with the protocol. More data? I will also ask for anyone who works with encryption, does any of that look like RSA to you? And you literally with our tools, you can basically cut and paste into transmitter, you know, simple replay attack. No problem at all. My tool even also regenerate the CRC for you if you decide to change stuff in the packet. That if we have a lamp. Yes, we tried to get a lamp for this room to get the light bulb and the clock, but it's really hard to get a lamp in a hotel. We tried. We even stopped by stores trying to find a lamp. Preferably, you know, the the stocking lamp, the leg. No one sold it around here. We looked. So, and I've attempted to sync this to the lock controller through the light switch to get to the lock. And I do not believe I got it fully working. Incorrect, but And unhappy Python code. Yeah. But the lock does in fact actually work if you push the button and remember to bring all the gateway parts not to the ones you only think you need. Yeah, that was my bad. I was packing things up from Berkeley to fly out here. I forgot the instian controller for the lock. I bought one on Amazon yesterday, had it FedExed out, and it doesn't seem to want to talk to my lock. My bad. Also, to note, if you want to use any of this, when you run the script and exit it, the RF cat will stop working until you unplug it and plug it back in. RF cat is lovely. The standard debugging strategy applies. Although one thing I have learned about, the RF cat is a wonderful device, but it is really finicky. And what acts with the pain in the ass with this protocol is RF cat likes either extra data or non-measured data. Unfortunately, with the instian protocol, it's 26 bits of Manchester, two ones in 26 bits of Manchester, so the dongle will not receive it. The workaround for that is you simply put the dongle into carrier mode without a sync bit and you receive and decode the raw data for yourself. And we transmit very similar RF cat will transmit its own preamble, the code ignores it and then transmits things. The most annoying thing is I meant to actually put it up here is that because of the two ones between the Manchester, you look at the data and you see four ones in a row, three ones in a row, something that's not supposed to have existed in the data stream. I bang my head on the wall for about a month. I was basically looking at my demodulator, what I do wrong, here's my timing off, what's going on here. Finally dug into it, no. They just broke the Manchester encoding. The question is they provide different documentation of vendors. I've asked the vendors, they told me they're on nondisclosure and can't talk to me about that. There is a command to turn off RF in devices. But again, they weren't allowed to tell me that command, your nondisclosure. I'm working on that. I plan to reverse engineer. Now I can read protocols and transmit protocols. So we have a tradition here at DEF CON for our first time speakers. Many of you might be familiar with it. Usually my cohort in crime comes out here with a giant bottle of Jack. But he absconded with it. So I have a bottle of Jack. Now also equally funny, this is a tradition for first time speakers. Now what's funny is Pete's not a first time speaker at DEF CON. He is. Which is hilarious to me. Because I was like you know. So Pete's been speaking at DEF CON since like six. So yeah, and you, you, you. Hello, I am the FNG. Don't trick me yet. He's coming up? No, he's not a first time speaker. He's cool. So congratulations, you made it to DEF CON. DEF CON. Thanks for the donation of chess here after the talk. See any of the three of us and we'll be glad to donate. So back to the slides here. Leave it that way. You scroll back up a little bit to be like a clean packet. In here. When I wrote my tools, by the way, I wanted to avoid byte order problems, so all byte code talks to each other in ones and zeros. So my demodulator spits out ones and zeros and it deals with that. Are you familiar with NetPBM? Yeah. That's how Jeff Fosk has got it on the problem. That's how I got it on the problem, which makes my code a lot more portable. I wrote my tools not just for Insteon. My demodulator works without knowing the offset. I have to give a talk before you to death right now and how to use Arc-Tan to demodulate stuff without having to do any tests for any transform. Trust me, it'll kill you. But what I'll show you here is they invert the ones and zeros. So we talked about the two ones. So in this case, that's the end of a new packet, new line. You're going to have one-zero, one-zero, one-zero and we're the bastards. You can see three zeros right there, three ones as another packet another set of three ones right there and those are all the cases of the codes you can't de-manchester it. Yes, I'm calling zeros ones because they invert the frequency shift. I really think a bunch of guys sat on a table with a bunch of beer and like, let's make this hard. I know, we'll flip it over. Oh, we'll also do reverse bits. Let's put a couple of things to screw with you. As you can see, it worked. The question is, how's it compared to the power line protocol? I have no idea. I'm afraid to hook up my gear to power line. If you would like to hook up your gear to the power line, we will watch and put it on YouTube. We're working the code effectively. My software written is trying to be universal, it works. I've tried to apply it to two other things, my demodulator, which I wrote for this. I've used it on a key fob. Demodulator, no problem. Hopefully these tools will move on to be useful for other protocols to crack. I really tried to write some slides on how I actually cracked the protocol. I really can't say how. I basically stared at it until it came to me. I literally, like I said, I wrote an XOR program. I could have said Gideon's Bible, but it came out. Finally, I stretched the screen out wide and I started seeing the rivers and streams in the data. Once I saw the rivers and streams in the data, I saw those patterns. That's just a matter of analyzing the patterns. I really hope to just talk to you and say, this is how you walk through to crack the protocol. I did it. I just stared at it, eventually saw the patterns. The human mind kind of led me enough to start to read it technically. Sorry. Also for anyone curious, this is the command that would have actually turned on a lamp had we had one. Well, how do we do on time? Severely, painfully early. Let's see. Well, I guess we have time for questions. Yeah, we're running, yeah. We're running the best talk. I guess we have time for Q&A. I thought we'd escape the crowd. You can replay back. Or if you have a program to PLM, it's almost the same command, it's a slightly different order. So yes, you can do cut and paste and do playback if you want with the hexadecimal. Or you can just reconstruct it yourself. Yes? The question is how to mitigate this. There isn't any real way of mitigating this. As I mentioned before, you can turn off RF in your house. And fortunately, there's no way of doing that because the command exists in the devices, but it's not public. Hopefully, I'll be able to reverse engineer this. I'll sacrifice a few lights. We're supposed to send random commands to it. But there is a way of fixing it. Hopefully, you can stay on after this talk. We'll put out a fix. I'll actually turn off the RF so that your house isn't full of transmitters. And by this, it's 950 megahertz. A decent 950 megahertz antenna. Oh, that's a good point. I'm going to get to that. These devices are not firmware-upgradable. Yes, at 70-hour light switch, you have your wall cannot be upgraded. Yeah? I don't own a Z-Wave yet. I do have a bridge for it. Z-Wave is actually encrypted. Questions? We head to the bar. Yeah? The customer is for cost money. I have posted on their internal forums. I'm doing this. Why are you going to talk about it? Well, because they lied. And again, as I pointed out, yes, turn light bulbs on and off. It's not the end of the world. It's not going to bring down planes. It's not active terrorism. It's not true security. ISEAN has paired up with Nest, Google, other big partners, to be the baseband communication between that and other devices in your house. It's a weak link. Let's address it before it becomes the weak link. ISEAN is making about halfway across my 1500 square foot house. I have a nice 5 or 9 dB antenna. No problem. As you know, with radio, if you can see it, you can control it. Questions, answers, accusations. All devices, all devices, all devices repeat. So if you have a light switch, if you have a light switch and a control device which are on a hard wire, all your switches will also bridge at RF also. All repeaters repeat everything. That gets our limit to a 3 hop count, but that makes it 3 network anyway. I think I can actually demo that real quick. What's that? Yes, Defconn will get the slides. They'll put them up in places. And I guess we'll... And the slides will also include a... My github is Evil Peach. And I meant to have the slide up there, but I'll put my computer up again, but thank you slides. Evil Peach at github, when I sober up on Monday, when I get home, I'll post all the code up there. So if you will notice, I was able to get this paired, but right here at the bottom, these are the commands from the from the lock controller. When I push the button and undid the lock, and if I unplug the light switch, you should not see those repeat. Basically those are the commands on lock the front door. Well, I guess we're done early. I'm not going to waste your time. Enjoy.