We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Insteon' False Security and Deceptive Documentation

00:00

Formal Metadata

Title
Insteon' False Security and Deceptive Documentation
Title of Series
Number of Parts
109
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Insteon is a leading home automation solution for controlling lights, locks, alarms, and much more. More than forty percent of homes with automation installed use Insteon. For the last fifteen years, Insteon has published detailed documentation of their protocols—documentation that is purposely misleading, filled with errors, and at times deliberately obfuscated. As my research over the last year has revealed, this sad state of affairs is the direct result of Insteon papering over the fact that it is trivial to wirelessly take control, reprogram, and monitoring any Insteon installation. Worse still, the embedded nature of the Insteon protocol coupled with devices that do not support flash updates means that there are no current fixes or workarounds short of ripping out the Insteon products. I will be presenting my research, and releasing tools demonstrating the vulnerabilities throughout the Insteon home automation system. Speaker Bios: Peter Shipley has been working with security for over 30 years. In the late 80's he wrote one of the first network security scanners and maintained one of the first bug databases ( later used to seed similar lists at CERT and llnl.gov ). Around the same time Peter co-founded UC Berkeley's OCF (Open Computing Facility). In the mid 90's Peter Shipley became a founding member of cypherpunks & setup up one of the first official PGP distribution sites. In '98 (DEF CON 6) Peter Shipley did a independent security research on war-dialing, exposing a significant security problem that was being ignored in most corporate environments making phone security. At DEF CON 9 Peter Shipley introduced wardriving to the world. Recently Peter has written and released several APIs using python to link various networked automation appliances via REST and other interfaces. Peter Shipley currently manages for a dot-com by day, and helps raise two kids by night. Ryan Gooler (@jippen) is a cloud security guy, known for luck, sarcasm, and getting into things. Avid lockpicker, lover of cats, and disrespector of authority.
32
Thumbnail
45:07
BitLine (geometry)Computer virusInformation securityCommunications protocolEndliche ModelltheorieDemo (music)Computer animation
TelecommunicationDuality (mathematics)Musical ensembleCommunications protocolFrequencyThermische ZustandsgleichungInformation securityCommunications protocolEndliche ModelltheorieWireless LANLecture/Conference
FrequencyProduct (business)ChainMereologyMilitary baseLink (knot theory)Information securityGame controllerDuality (mathematics)Physical systemThermische ZustandsgleichungGoodness of fitOperator (mathematics)Musical ensembleAdditionBridging (networking)GoogolTesselationAndroid (robot)Game controllerWindows LiveLecture/Conference
CodeProduct (business)Level (video gaming)Integrated development environmentState of matterGoodness of fitBridging (networking)Communications protocolRemote administrationVulnerability (computing)CodeIntegrated development environmentPhysical systemLink (knot theory)Remote procedure callVector potentialOpen setVulnerability (computing)OSI model
Communications protocolLatent heatGoogolProduct (business)Covering spaceInformation securityCommunications protocolGoogol
CodeProgrammer (hardware)Normal (geometry)Communications protocolComputer-assisted translationClient (computing)Mixed realityWriting
Communications protocolDisk read-and-write headSpacetimeSolid geometryMereologyReverse engineering
CodeFrequencyShift operatorMereologyCommunications protocolSymbol tableBit rateSymbol tableStandard deviation
FrequencyShift operatorStandard deviationFrequencyShift operatorAbsolute valueModul <Datentyp>Symbol tableStandard deviationCharge carrierLecture/Conference
FrequencyShift operatorBitBit rateClosed setSymbol tableFrequencyShift operatorAbsolute valueBit rateSymbol tableStandard deviation
Order (biology)TransmitterCodeSynchronizationFile formatFlagStandard deviationMessage passing
Order (biology)Combinational logicComputer programmingBitQuicksortCoprocessorData storage deviceEncryptionAddress spaceFlagOrder (biology)Subject indexingComputer configurationFile format
TouchscreenFigurate numberSubject indexingCodierung <Programmierung>Inverter (logic gate)Lecture/Conference
Video gameSubject indexingBitLine (geometry)Core dumpCodierung <Programmierung>Subject indexingMaxima and minimaCodierung <Programmierung>Inverter (logic gate)FlagMessage passingLecture/Conference
Shift registerLimit (category theory)Carry (arithmetic)Message passingMathematical analysisLie groupShift operatorMaxima and minimaExtension (kinesiology)Tape driveMassLinear feedback shift registerFlagMessage passingLecture/Conference
MereologySlide ruleWebsiteCodeShift operatorShift registerDiallyl disulfideExclusive or
PeripheralSoftwareLevel (video gaming)Physical systemPhysicalismSlide ruleLink (knot theory)Information securityFirmwareCommunications protocolWeb pageGame controllerSoftwareLevel (video gaming)PhysicalismLink (knot theory)MassField (computer science)Information securityFirmwareAddress spaceMessage passingGame controller
Information securityEncryptionAddress spaceUniqueness quantificationInformation securityFirmwareCommunications protocolEncryptionAddress spaceEndliche Modelltheorie
Formal languageLine (geometry)Extension (kinesiology)Slide ruleCommunications protocolEncryptionComputer wormMessage passingCodeExtension (kinesiology)Physical systemInformation securityCommunications protocolEncryptionCartesian coordinate systemAdvanced Encryption StandardStandard deviationComputer wormMessage passing
EncryptionData transmissionReverse engineeringIntelligent NetworkCommunications protocolEncryptionDirection (geometry)Cloud computing
InformationShift operatorSlide ruleLinearizationGoodness of fitProcess (computing)SummierbarkeitCommunications protocolSound effectSoftware-defined radioMultiplication signFeedbackSoftwareShift registerReverse engineeringStandard deviationCyclic redundancy check
BitExclusive orEquals signMathematical analysisPermutation
InformationMathematicsShift operatorElectric generatorBitExclusive orOcean currentCyclic redundancy check
AlgorithmShift operatorDot productCASE <Informatik>Identity managementBitView (database)
AlgorithmComputer hardwareMultiplication signStandard deviationDiallyl disulfideTranslation (relic)Modul <Datentyp>Communications protocolReverse engineeringStandard deviationLecture/Conference
Computer hardwareHacker (term)Physical systemStreaming mediaStandard deviationComputer-assisted translationComputer hardwareHacker (term)Group action
VideoconferencingLecture/Conference
Lecture/Conference
CodeFunction (mathematics)SynchronizationBitGateway (telecommunications)Similarity (geometry)Strategy gameAsynchronous Transfer ModeData storage deviceCommunications protocolScripting languageAddress spaceFerry CorstenTransmissionskoeffizientTouchscreenIntrusion detection systemFlagStandard deviationCharge carrierSoftware protection dongleRaw image formatGame controllerComputer-assisted translation1 (number)
CodeTransmitterCodierung <Programmierung>Data streamDisk read-and-write headDifferent (Kate Ryan album)
CodeOrder (biology)Transformation (genetics)CodeShift operatorBitLine (geometry)Slide ruleTable (information)WeightCASE <Informatik>Set (mathematics)Communications protocolReverse engineeringNP-hardElectric power transmissionSinc functionMultiplication signPortable communications device1 (number)Computer animation
CodeUniverse (mathematics)Power (physics)Communications protocolExclusive orHookingElectric power transmissionYouTube
Computer programmingCommunications protocolStreaming mediaPattern language
Escape characterMultiplication sign
CodeTelecommunicationSlide ruleCountingLink (knot theory)Goodness of fitRange (statistics)Information securityFirmwareSquare numberBridging (networking)WaveAddress spaceInternet forumTransmissionskoeffizientRight angleGame controller
Bridging (networking)DecimalComputer animation
Transcript: English(auto-generated)
Hello. I'm Peter 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. I plan to go over things. I'm going to give you a conclusion and talk about how I got there.
It's a wireless protocol. A bunch of devices like this, plug around your house, get a home controller, lights on and off, sprinkler systems. I got bored and set my house up with
it and started playing with it. Technology is run by a wireless or RF protocols. Dual band communication which is an asset and a problem as we'll soon see. All the bases are
capable as a repeater. So effectively any light switch in your house is also a radio frequency repeater. Really easy to pick up their signals. Now, what are they good for? Well, they paired with Google's nest and they paired with Microsoft's. I've never seen it yet. This is why it's
relevant. Incyon by itself is a security problem. They're being paired up with more and more automation. More of a product. This is the weakest link. I'm giving this talk so the weakest link doesn't become part of the chain. Things you
can do with it. I'm not trying to sell you the product here. Turn your lights on and off, control your sprinklers remotely if you wish. You have I O controllers so you can add water pumps. All the usual things. As I mentioned about the weakest link, it's a protocol for lighting
environment. It's integrated to many, many other things. And this is a problem. For example, we have a lock on stage here. With this and RF cat, you can pretty much open that lock. I'd like to point out here, the lock is a good lock.
It's not medico, but it's operate state lock. And the remote control is a rolling key code. So the product is pretty good. The weakness is the Incyon bridge to it. For those familiar with Incyon, you might have read their papers. They published specification on their RF protocol. Just Google
white paper. It's 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 comparing themselves to other wireless protocols. You can read
that if you want, but you don't really need to. Well, three of the specs, being a hacker, I decided, you know, I can embed this with RF cat. I'm a pretty good programmer. I've worked for 20 years. So I wrote code to do it. My code didn't work. It failed spectacularly. Normally my code doesn't fail
that bad. Just a little bit. This is interesting. I tried to get the packets, I was getting nothing. So I investigated. I successfully reverse engineered the protocol. Took me a while. A lot of head banging. A lot of my
protocol documentation is so full of shit. They ran out of ways of saying bullshit my documentation. One of my things I can do is space operas on my kindle. I have space operas that contain less fiction than the protocol documentation. Fortunately my friends are friends. Let's get
on to the fun part here. Let's talk about the protocol that we were talking about. 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 k just enough to make your demodulation a pain
in the ass. Manchester coding. Bullshit. You can't decode it with Manchester. Believe it or not, they actually use frequency shift modulation. Bullshit. Bullshit. Bullshit.
A 3% bullshit. It describes as symbols that are modulated using frequency shift key and blah, blah, blah. Bullshit and
Klingon. If you want to be more accurate, the frequency is the deviation. Actually back up there a little bit. They actually got that a little bit wrong. Deviation is a shift to the center frequency to the one or the zero. Not the entire
thing. They got that wrong. Bullshit. So let's just say this was a typo. We're going to be nice to them. 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. On that point, what the actual spec is, as you can see this is the real spec. Real frequency is a little bit off. I love how they claim to be a little bit 3,000 data
rate. It's more like 2,600k. The symbol rate, not even close. Look at the standard packet format. This is standard packet that you expect to see something transmitted. Who here
thinks that's accurate? Come on. The extended packet. Not
even close. This is actual packet order. Back up a little bit. 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 they ordered by byte. I figured out how the bits are encoded here. I wrote a program called X sort. Since I know the MAC address on my devices, I figured the processor encryption would be that hard. So I wrote a program that takes my
MAC addresses, flips them, reverses them, inverts it and X stores every possible combination of my MAC address against the packet. I was getting lots of hits. Someone pointed out I could feed Giddings 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. My laser is missing. Two points off of me as a speaker
for not being ready. I can't even see my own screens. Effectively, this is how it's encoded. Here's three bytes. Don't worry about it. Don't figure it out. Effectively,
the three bytes, every byte is actually encoded with, oh, back up one. So we're just going to look at how three
bytes are encoded. The first three bytes are O3, E5. The packet is actually with a five bit index number. Followed by the eight bits. It's transmitted the least significant bit first. So we flip that whole thing over. And
then Manchester encoded. To make your life just wonderful. And actually the lines at the top, that's actually a raw dump of the whole thing. Three bytes of packets. Very, very inefficient method of transmitting this stuff. Well, three and a half to something. And the data effectively, the
packets, this is actually from the documentation and actually correct, believe it or not. Shocking. I think the only thing in the documentation that was accurate. Also talks about the message byte and carry. 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 limitation which by the way, the second half was talking about how I cracked the CRC which is a pretty good thing. They basically shake the XOR,
shift the upper interval. I tried to describe this and I tried to work this slide out. You can actually read what I'm talking about. It's just easier to say this. And yes, this will all be published and I have a website with all documentation for this. Now for the fun part. It claims to be
secure. The security to quote them, if I want to read my own slides here, is maintain a two level security, a link control system where users cannot create links without physical access to devices. Bullshit. And basically you need to have possession of physical device. Then two or three pages
later the documentation talks about software pairing. If you want to. 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? Exactly. They claim they masked the high bytes of all traffic. Did I mention the RF protocol a few minutes ago? You think we have a problem with the security here? Yeah.
Basically they call it note addresses, I call it Mac addresses. Easier to think that way. And they encrypt with basically unencrypted. So there is no security. They actually published an entire white paper describing their
security versus Zigbee which is an encrypted protocol and showing how they're superior. Another multiple thing that really annoys me is their claim of encryption. If you're a security person, 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 instead of messages. This is not quite true. They support encryption just like any other layer 2 protocol does. You can pass a packet that is encrypted. If you read between the lines here, they say their
extended packets can contain encrypted payloads. It does not say they're actually encrypted. You tell who speaks what language or who laughs while you change the slides here. There is actually a 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. You go through all the documentation, they mention
they're encrypted about every chapter. Bullshit. I've never seen a company lie so heavily about the documentation and it would be so clear text and transmission. So let's get to the more technical stuff here. How about reverse
engineering? Originally in this talk I was going to say something to the effect of how I cracked the radio protocol and all that stuff. Everybody here has been to an SDR talk the last couple of years about how to crack a radio. Honestly, go with fun with IP or something like that. Those guys are just as good a job as I would at documenting how to reverse engineering protocol. I'm not going to waste your time. What
we'll talk about is a check sum. When I need to crack a check sum for this thing, it took me a while. There wasn't any good documentation on it. I read a lot of academic papers, talked to some technologists, nobody gave me good information on how to crack a CRC so I figured out my slides and explained to you how you're going to crack a CRC if you ever need to. It's actually not that hard once you figure it
out. Their documentation claims to have a sub linear shift register. Bullshit. So I look at this. Here's an example of some actual packets. If you bring the packets together, if I XOR the packets, the equal sign is what the XOR equates
to. If you notice the first one, it always ends at zero. That effectively tells me that the second nibble or the lower end nibble is a simple XOR. The upper end nibble is not. Never found a little bit how to crack the whole thing. Next
week we want to crack a CRC, what we want you to do is look at the higher nibble. So because I was able to generate packets, I generate 255 packets on 255 values, I was able to generate packets of various information. What I did
was, I simply XOR the packets together. The resulting data is only the changed bits. What you see here is the packets XORed with themselves to only see the bits that have changed. As you see here, the upper nibble doesn't affect anything. Obviously it's not sub linear shift. Next thing you
do is you 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, make it easier to read or place the zeros with dots. From here you can clearly see how the
algorithm works. A little clearer might be this. In this case the algorithm is very simple. You take the first nibble, shift by one, XOR with itself, apply it to the upper end. Again, proving they lied. Again, that's the
algorithm. I'm not going to waste your time with that one.
I've written tools for this. I hope it's 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 TV donkles, RF cat and hack RF.
I have a demodulator for this. Here's an example command. Read and decode live streams of the data. With the live streams you can play, replay and attack systems. To transmit a packet, same thing. After this we'll give a
demonstration of the software. After that we'll have a question and answer. Tough crowd. Run a little ahead of schedule. Hopefully some of this will work. Likely none of
it will. We'll see. No video. Awesome. Okay. Cool. 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 Pete's fault. So very simply we've got a couple of scripts here. One is 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. How 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 117828 here is I believe one of the lights that we do not have
hooked up because we couldn't find a lamp. And the other IDs 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 will be posted after the talk. Now it works. The flags here which is the only thing that is
correctly documented in the protocol. You've got your from address, your to address. 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 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 a transmitter. Simple replay attack. No problem at all. My tool even also regenerates the CRC for you
if you decide to change something to pack it. We could prove that if we had a lamp. Yes, we tried to get a lamp for this room so we could get the light bulb in 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 the stocking lamp. No one sold it around here. We
looked. And I've attempted to sync this to the clock controller through the light switch to get to the lock and I
do not believe I got it fully working. Incorrect. And unhappy python code. But the lock does in fact actually work if you push the button and bring all the gateway
parts, not the ones you only think you need. That was my bad. I was packing things up from Berkeley to fly out here. I forgot the 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. The RF cat is lovely. Standard debugging strategy applies. The RF cat is a wonderful device but really
finicky. And the pain they ask for this protocol is RF cat likes either Manchester data or non Manchester data. Unfortunately with the instant protocol, it's 26 bits of Manchester, two 1s and 26 bits of Manchester so the dongle will not receive it. The work around for that is you simply put the dongle into carrier mode without a sync bit
and you receive it and decode the raw data for yourself. And we transmit very similar RF cat will transmit its own, 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 1s between the Manchester, you
look at the data and you see four 1s in a row, three 1s in a row, something that's not supposed to exist in the data stream. I banged my head on the wall for about a month. I was basically looking at my demodulator, what I do wrong, my timing off. What's going on here? Finally dug into it. No. They just broke the Manchester encoding. The
question is different documentation of vendors. I asked the vendors. They told me they are non-disclosure 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, non-disclosure. I'm working on that. I plan to reverse engineer. 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. Now, 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 is not a first time speaker at DEF CON. He is. Which is hilarious to me. Because I was like, you know,
so Pete has been speaking at DEF CON since like six. And you, you, you. Hello, I'm the FNG. He's not a first time
speaker. He's cool. So congratulations, you made it to DEF CON. See any of the three of us and we'll be glad to
donate. So back to the slides here. You scroll back up a little bit. In here, when I wrote my tools, by the way, I
wanted to avoid byte order problems. So all my code actually talks to each other in ones and zeros. So my demodulator spits out ones and zeros. Every here familiar with net PBM? Yeah. So that's how I got around the problem. That's how I got around 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 get to give a talk and bore you to death right now on how to use arc ten to demodulate stuff without having to do any transform. Trust me, it will kill you. I want to show you something here. Remember I told you they invert the ones and
zeros. So we talk about the two ones. So in this case, we have a new packet, new line. You're going to have 101010. And we're the bastards. I can see three zeros right there. Three ones. Another packet. Another set of three ones right
there. And those are all the cases they put the extra ones into the codes. Yes, I'm calling zeros ones because they invert the frequency shift. I really think a bunch of guys sat at a table with a bunch of beer. Let's make this hard. I know. We'll flip it over. We'll do reverse bits. Let's
put a couple of things of screw with you. As you can see, it worked. How does it compare to the power line protocol? I have no idea. I'm afraid to hook up my gear to the power line. If you would like to hook up your gear to the power line, we will watch and put it on YouTube. We'll work
the code effectively. Universal works. I've tried to do two other things. I've used it on the key fob. No problem. Hopefully these tools will move on to be used for other protocols to crack. I really tried to write some slides on
how I cracked the protocol. I really can't say how. I basically stared at it until it came to me. I wrote an XOR program. Finally I stretched the screen out wide and started seeing the rivers and streams of the data. Once I saw the
rivers and streams of the data, I saw the patterns. It's just a matter of analyzing the patterns. I really hope to just talk to you and say this is how you walked through the protocol. I can't say how I did it. I just stared at it and saw the patterns. The human mind led me. Sorry.
Also for anyone curious, this is the command that would have actually turned on a lamp had we had one. How are we doing on time? Severely painfully early. Let's see. I guess we
have time for questions. I guess we have time for Q&A. If thought we'd escape the crowd. If you're programmed to PLM it's
almost the same command. You can do cut and paste if you want with the hexadecimal or you can reconstruct it yourself. The question is how to mitigate this. There isn't
any real way of mitigating this. You can turn off RF in your house. 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. There is a way of fixing it. Hopefully after this talk we'll put out a fix. Your house isn't full of transmitters. This is 950 megahertz. I've got a pretty good range on that. These devices are not
firmware upgradeable. You have your wall cannot be upgraded. I don't own any Z wave yet. I do have a bridge for it. Z
wave is actually encrypted. Questions? We head to the bar. The customer support costs money. I have posted on their
internal forums. That's not a security problem. Why are you going to talk about it? Well, because they lied. As I pointed out, you have to turn light bulbs on. It's not the end of the world. It's not an act of terrorism. It's not true security. But it's paired up with nest, Google and other big partners to be the base band communication between that
and other devices in your house. It's a weak link. Let's address it before it becomes the weak link. How big is your device? Their device themselves make it about halfway across my 1500 square foot house. I have a nice five or nine DB
antenna. No problem. With radio, if you can see it, you can control it. Questions, answers, accusations? All
devices repeat. So if you have a light switch or a control device which are hard wire, all your switches will also bridge it. There's no stop. All repeaters repeat everything. Packets are limited to a three-hop count but that makes sense to your network anyway. I think I can actually demo
that real quick. What's that? Yes, we'll get the slides. We'll put them up places. And the slides will also include my get-up. My get-up is evil peach. I meant to have slides. When I sober up on Monday, I'll post all the code
up there. So if you will notice, I wasn't able to get this paired. But right here at the bottom, these are the commands from the lock controller when I pushed the
button and undid the lock. And if I unplug the light switch, you should not see those repeat. Those are the commands that unlock the front door. I guess we're done early.
I'm not going to waste your time. Enjoy.