 We have Daryl Highland from RapidSeven and he's presenting his talk called Internet of Vulnerabilities. So take it away. Thank you. Thank you. How's everyone doing? Outstanding. So again, my name is Daryl Highland. I am the research lead for IOT Technology at RapidSeven and hopefully you guys will enjoy this presentation and I'll be around after the presentation and clear until Monday so you know kind of grab me and we can grab a drink and have some discussions. I'm always open to feedback stuff you're working on and we can talk about stuff I'm working on that hasn't been published yet but not all the details. So it's kind of fun and this is generally a presentation on some of the work that I've done over the last 12, 14 months or so. Some smaller items kind of more of the junk hacking but kind of looked at it from a, you know, what kind of privacy issues maybe exist all the way up to enterprise level technology so it should be kind of fun. So from a perspective of IOT research, when I came over at RapidSeven and took over the position as the research lead, one of the first questions I was asked was, now you're a research lead, what the hell's IOT? And I think you all realize, you know, trying to define a definition of what IOT is is very difficult. So instead of doing that approach I kind of try to hit the 80-20 type thing but kind of frame it around how do we approach looking at the security of IOT technology. And I kind of use this model here. It's a group of three general pieces. You know, we always have the hardware aspect of IOT which is we're all into hacking the hardware. But the hardware is only one small piece of the overall puzzle. And some of the other pieces we often run into are mobile, the mobile application aspects that interface with this technology. The cloud services, cloud APIs. So the ultimate goal was, as the research lead and as I drive research and IOT testing within RapidSeven, was, well let's approach this from an ecosystem, a full ecosystem of an IOT product. That way we can examine the impact of one aspect of that ecosystem on the other. What's the impact of hardware vulnerabilities to cloud information, cloud data, cloud APIs? What's the impact of mobile applications on the hardware or on the cloud APIs? And vice versa across this. And that way any time I approach a technology, I look at the entire ecosystem, all the pieces. So in this talk we're going to, a lot of it's going to be covered. It's going to be some of the outline pieces. It's not all going to be hardware. We're going to talk about web, web API, vulnerability issues are part of the product line. And we're going to look at mobile application vulnerabilities. Generally the most common one that they seem to find on everyone which is definitely going to get it fixed. Let's kind of look at that. Coming out of that, we kind of build a methodology for approach in IOT testing. And it covers these general areas, you know, functional evaluation all the way down to examining the art radio RF. And the goal is to dive into each one of these in detail across that ecosystem. If you do that, you're going to get a more holistic view of the security of that technology which makes it all that much easier to actually get the technology fixed. Which is what we're all about. We're not, it's not about vulnerabilities, it's about fixing the issues. So let's kind of move forward on this and start talking about some of the IOT hacky. So what we're going to talk about today is some vulnerability issues we found around automated lighting solutions. We're going to talk about BLE tracking dongos. And actually I think they're actually using one back here as part of the contest. It's actually, I believe, one of the tracker, our bravos. So we'll be talking about that one specifically because it was like, had some serious problems, especially with the cloud APIs. We're going to talk about telepresence robots. I don't know if you've ever seen those crazy freaking robots. It's like an iPad on a segue. So we're going to talk about issues discovered there. And then we're also going to talk about a GPS panic button. And this one has a really interesting story around it. I think you guys will find maybe not funny, but at least entertaining. So let's kind of move forward. So looking at automated lighting solutions, and what we looked at was the Selvania Audra products, the Lightify products. And there's two pieces of the Lightify products. There is the home user modules, which we have one here kind of all gutted out. And there was the enterprise version. This is what's used in businesses, organizations that can use to manage lighting within a building. Things we found, you know, the common unencrypted storage of information, poor encryption and communication, unauthenticated controls, and embedded web phones. Remember a lot of this technology, especially as you move into the enterprise stuff, all have web servers. And those web servers are wrought with issues. So let's go ahead and start off. We'll start off with, starting out with, I manned up and set up the home Lightify system. And started looking at the mobile applications. And the first thing I found was the WPA pre-shared keys, actually stored unencrypted on the device, whether it was an Android or IoT, it was stored unencrypted. The crazy thing is, is this didn't need to be stored there after the system was set up, but it continued to store it there. You could log out, you could do whatever you wanted to do, reboot the device, and still this data was in there. And you know, how often do we lose our phones? I guess if you're on iOS, it's a little more security built in that. But if you're on Android, what's security? Okay, so think about it. This is a common vulnerability. I find this over and over and over on probably 80% of the products I look at. I'm finding user IDs, OOP tokens, pre-shared keys, all the information stored right there on the device, giving it ability to do anything from taking over the device, taking over the home wireless to actually taking over all the cloud APIs and controlling the person's entire home in some cases. And this is definitely something we need to get fixed. So my goal is, if you're out there doing IoT research, look at this stuff, look at the mobile applications, try to identify this stuff and report it out there. I've already reported, you know, a systemic issue across all the products. Now we need to get it fixed, because this isn't saying there's solutions to prevent this type of stuff. Moving from there, we started looking at the home enterprise devices and how they have their user name and passwords for the Wi-Fi. So these devices often, when they fire up, have a Wi-Fi solution that's actually available. You connect to it and it's often used to configure the device. So we started looking at those default for that particular device, their SSID and the WPA pre-shared keys that are associated with the configuration of these devices and go, well, how secure are these? So we jump over here on the, this is the home, this is the home product, okay, right here. And we can see it's 8 characters, 10 characters, African American, upper or lower case. Not perfect, but in reality, not that bad. So I get the enterprise product and I start looking at it. Now the big thing with the enterprise product is it actually has ethernet on it. It has Wi-Fi, so you can get access to it to Wi-Fi, and then it can also integrate to your building or your internal Wi-Fi system. So it has multiple ways for communication and literally all of them can function at the same time based on how the device is configured. So when we started looking at the actual WPA pre-shared key on this device here, we noticed that it was only 8 characters, but I couldn't, you know, figure out, you know, is it Alfa and America, upper lower case and all that type of stuff. So I had them give me a second device. Once I got the second device, the answer become clear. It's actually Hex, A through F, 0 through 9, 8 characters only. So instantly we set this thing up like it was in an enterprise. We hooked it on the ethernet, its Wi-Fi came up running, you could connect the management console into the Wi-Fi or the ethernet, but if you're connected through the Wi-Fi, a typical WPA pre-shared key attack, you kick them off, they rejoin, you capture the data, and apparently I don't have that slide in there anymore, but the crack was, used at a really shitty GPU, we cracked that in less, right around two hours. So instantly a device in an enterprise, not configured, not shutting that stuff off, which may be very common using really bad pre-shared key, key space, we quickly cracked this in two hours or less, given an attacker to be able to gain access to an internal network fairly quickly. So also this device happened to have a web server. We found a couple vulnerabilities on there. So the first one was when I was logging onto the device, I'm going down through the list and I go security logs. I always like something when it says security logs. That's always the greatest thing. So I go into the security logs and I notice it showed the username of my log on. So I came back out and tried logging on with a bogus name, went back into logs and it had that name in there. So I thought, oh, what the hell? Cross-site scripting, persistent in the security logs. So I gave it a little present of a laughing skull. So also on the web server we found some issues in the configuration page, the management configuration page for the actual Wi-Fi setup. And I don't know, when you're looking at a Wi-Fi configuration page and you see this page, what do you think? I often ask the school, what's the first thing that goes to your head? The first thing that goes to my head, it's another injection point for actually injecting cross-site scripting into a management console in a system. But it's an out of band, which we often don't look at. Because we're, you know, don't people don't think? An SSID can be built, the SSID name can be built to contain Java code. It can be configured to make calls out to a server and pull down Java code. So I have a quick video here, a little bit for entertainment. So I actually spoke at Black Hat in 2013 and I presented a paper on attacking embedded devices via SSIDs. I don't know how well it's easy to see this, but. So we come over here and we go to the Wi-Fi configuration and we quickly see that, that we can actually see the Wi-Fi access points in close proximity. So we just basically set up our little own special SSID, which is always fun. So a soft access point we fired up. So we can check to see what does the application do when it interacts with a Wi-Fi injection. So I've used this, I've used this attack a number of times over the years. So something to consider when you're engaging this, don't always think about just cross-site scripting. If you go back and look at the paper I published here on this particular attack vector, we actually found formats during attacks via this vector also. So there's a number of things you can carry out via SSIDs against embedded technologies that contain web services. So a number of the one of the things, something to consider, anytime you're testing any kind of IoT technology, you're used to testing it in all the normal conditions. Well we also get a contestant in what's considered abnormal conditions. How does the equipment affect or act when it loses access to its cloud APIs? Often the technology, especially home automation, will go into a local control mode. Local control mode means there's going to be some kind of service exposed locally, giving the ability to connect to that device. Often that is not authenticated or encrypted data. It was the same way in this case, it actually had port 4,000 open. So we were able to capture all the communication and decode it and figure out how to control the device. Now I do have a demo here and I'm not sure how the whole Wi-Fi stuff is going to work in here, so it's lovely to go to hell in a hand basket. But either way we can talk for it if it fails. So a little bit of camera here. So we have a device right here and I'm going to go ahead and plug that in. Let's see if we can get another, let's see if we can double a couple screens up here. So this would be a little difficult, but let me see if we can do this. So a couple of interesting things you're going to see here. So you see the stuff in the background, I want you to be able to see the bulb, things start up. Okay, cannot, let's fix that. Demo gods, man. Either that or my device died. One of the two. Well we'll give it one more try and then we'll start to verbalize and throw it. Hopefully it didn't pump up the camera. Well unfortunately apparently my chicory just died. Life's a bitch, ain't it? Let's see if this is the right one. Okay. So unfortunately we can't do that live. What I was hoping to do was show the one command. Actually being able to make the device jump from one access point to another access point with a command. So it was unauthenticated but if you watch this screen there's a couple other interesting things to point out. This is the UART connection on the device. So in this case we don't get a full command shell, we get a small subset commands. But if you watch clearly I'm hoping it'll come up, it may not. But you'll see there goes, don't miss it. Password, device key, product key. It's actually calling out to China. So it's going out to China and connecting up. Looking at the data and what was being transferred, my best determination which was a good one was that it was connecting out for validating firmwares. The particular company it produces the underlying hardware here actually seems to be one of the better ones I've seen so far from the China perspective. And I couldn't determine it doing anything else. And couldn't figure out if they were doing anything else. It all seemed to be purely testing and validating firmwares. So if your firmware was out of date then it would send commands back via the APIs to communicate to you to be able to upgrade your systems. So it would flag your system and you start getting alerts to actually upgrade the firmware. And that was determined based on that information there. But you can see there's a couple subsets. You can identify various ports and stuff that are actually open on the device. So looking at the hardware to be able to get access. I mean anytime you open up a piece of hardware, if you're anything like me, the first thing you look for is where can I connect in to start looking at it. So we find these small pads and these are .1 millimeter pitch pads. And if you're an old man like me trying to solder those are a total bitch. So you can see how big the connector pins are. It's like I can't even see that good. So we got them soldered in pretty good. And like I tell everyone I cheat, I use a microscope. Which works really good. And again we can tap into those. So we step back here. This one happened to be in this case right here goes to the main processor on the device. And we give us the UR log dump as we were seeing there. So we can see what was going on. So you could do various things like if my card hadn't failed on me for some reason. You'd be able to actually see the device connect out to the internet to the cloud, get the connection. You would also see how it handled the command incoming command unauthenticated over port 4000. And try to drop off that one and try to connect out to a third party or do a different access point for control. And there's the whole rig with the shaker that apparently just died. I actually have a couple spares but we'll see if time I can slightly swap out. But we'll see. Let's get through the presentation first and see if anyone has any questions. Because I could easily show this to you offline. So the next one is a telepresence robot. And these things are truly freaky if you've ever seen them running around. Is anyone ever seen these running around in offices? Yeah it's pretty wild, you know. So I met a college professor at university and the first thing he asked me was, Daryl, have you ever seen these new telepresence robots? So he starts telling me about it. He says, well I have one, but it wasn't the full one. He had the desktop version. So he let me play around with it online and see how it all worked. So I was talking to some people rapid seven and going, you know, I'd be really cool to look at these things. And someone goes, you know, we like have two or three of these in the Cambridge office. So instantly I start prodding people. And they packed one up and shipped it to my house, which was totally cool. So I got to play with it running around the house. I wrecked it. First time I fired it up. It spun around, run across my office. It hit a wall and then wrecked. Luckily I didn't destroy it. I'm going to send this thing back in a paper bag. But luckily I sent it back fully functional. So in the case here, we had a couple things. The point, the first point is I didn't cut it open. Okay. I set and spent like three hours trying to figure out how to disassemble this thing. And I couldn't figure out how to safely do it without pulling the rotating wheels on it to gain access to the locking bolts. And the last thing I wanted to do was basically send back in a paper bag a $3,500 product that was actually being used by certain people in the company. So I didn't really focus on digging into the hardware and tearing it apart to see what I can get. But I did look at some other things. I looked at the cloud APIs, the communication. I looked at whether to handle Bluetooth pairing properly, those type of things. So the first thing, started looking at the API, man in the middle, the connectivity from the head to the cloud. And started looking at how this thing was communicating. And I instantly found out that the APIs had no freaking authentication to them. Several no authentication. So you take this URL right here, and it has this offset. If I set the offset as some astronomical number, it would air message back to me. And so that's invalid. The highest number is this. So, so the first thing I did was, you know, I threw that higher number in there. And I didn't know what the limit was. I set it like two or 300, just curious to see what would come back, thinking it would be my data and my data only. No, it wasn't. It was all data. It was data for every robot that was functioning that day. This particular data here is live tracking data of session communication as it happens on the particular device. It's all recorded into a database. So, instantly I step back. You know, there's a whole ethical issue at that point. I'm seeing other people's data step back, had the right legal conversations. We figured out how to appropriately narrow it down so I can only look at my data and try to focus on that because that's what we're after. We don't want other people's data. We want to be able to look at our data and consider the overall security of it. But if you set this offset at one and set the limit at a million, you would basically pull down all of the data for every robot since the thing was put into place for every robot on the face of the earth. And we get this session data. The session data wouldn't give me the ability to take full control because there was two communication paths. One of them was encrypted and pinned properly. And I couldn't break the pinning. I don't know what they were doing weird, but I couldn't get in the middle. It kept failing and causing the robot to fail. And so that was the case. So looking at another API here, very similar, that offset, you can set the number. This was for every registered robot out there. And it would return back installation key. But it also returned GPS coordinates, the name of the device. So literally, you could dump all the data, gain access, GPS coordinates for every robot that was issued in place functioning on the face of the earth. The third item that I started to look at was dealing with what's known as the robot key. This is the key to the kingdom. This one was a little more secure. You had to be able to be local enough to man in the middle of the device, okay? But it turned out that once you accomplished that, what the robot would do would send out a robot key information to the cloud, post it to the cloud. The cloud would return to you the username. Now, to start off with, to make the robot function, the only thing that had to be returned was the username. Because it went into a menu system where you can say how many users and add more new users. So the only thing needed was the username to be returned. But when you put in the robot key, it returned driver tokens. Driver tokens are nothing but session tokens that are assigned to somebody forever. So that means they, if they load the application on their laptop to be able to control the robot, they would connect out there and when they logged in, this session token or driver token was used for them to remote control the robot. So when you put this thing out there, robot key to the cloud, no authentication, it will return all the users and all the robot control keys for every user. Basically meaning that you could become anybody. So, so what I did here was out of curiosity, you know, like, okay, how can I mimic this? So if I did this, let's say I got the robot key, I go off over here, I post the robot key, it gives me the list, I put the application on my machine, I log on out there, create myself account, it would give me an account with no control of a robot, I would go into my session tokens, drop one of these in there and all the robots would show up. At that point, giving me full control of the robots. So yes, a seriously bad problem. Again, the customers were very receptive, the vendor was very receptive to this and we got these problems fixed quickly, which is always a plus. So the next one we want to look at is the BLE dongles. Now I looked at, I looked at like four or five of these, you know, the tile, this one, there's one called not, there was another one I was looking at at that time. And it was curious, and this was driven very much by the fact that I was seeing these people carrying these around under key chains all the time. Every time you turned around, it's like, oh, they had this weird dongle, whether it was a silver or a blue one or whatever the brand was, you know, and I started thinking, well, what kind of issues would be here? Obviously, I would consider more of a privacy issue. So it was like un-infinicated access was identified, weak BLE pairing, which is another common vulnerability we encounter, information leakage and insecure cloud APIs. So what we want to do is actually have one here. So my goal is to see if we can look at this and see, I'm surprised no one's hacked me yet. So apparently they're not doing anything good back there on these. There's no devices because I plugged it in to plug this in. What's that? I can't hear you. Oh, I'm sorry. Yeah, the purpose of the dongle is to be able to find your keys when you lose them. And the interesting thing with these devices, they use this thing called crowd GPS-ing. And the way that works is when you purchase one of these things and you set up the application on your phone, if you lose your device and you happen to lose it in the city park, how the hell you find it? The way you find it is you look on your phone and what it'll do is if anyone else running that application passes within proximity of this, it'll send the GPS data out to the cloud, showing you where you actually lost your device, taking advantage of everybody using the same product. And that's how most of them work. I'm not sure how well this will work on this screen here, but we'll see. So first thing I want to do is turn Bluetooth on, which may be a mistake. So we're going to see a shitload of stuff show up here. All the people that are either futzing with us or too stupid to turn their devices off. So the first thing I want to do is, so I have this device here and we're going to jump over to another screen now that that's turned on. And I don't know if anyone's ever used NRF Connect. I've been doing this, been installed before. Was there was? I didn't see it. Ah, thank you. My hand was over top of it. So let's do a scan. And this is going to detect Bluetooth low energy, which is what this device is using. Let's flush this old date out of here. So we can see, you can see all the people at DEF CON that didn't bother to turn off Bluetooth low energy. And the shit list goes on and on and on. So let's see if my device shows up and see if I can find it in here. So this is the fear anytime you do these in large audiences. Let's try again. So there's a tile. You can see the tile that was that's one of mine. Okay. Well the demo gods are being a total bitch today. I don't even see the device back there. But we're going to jump on something else. Weston, you jump up here, change the battery out in this. There's some batteries right there in the top. There's a little black hole. Yeah, it should be right there in the top in the case there. There's batteries. So let's go ahead and move on from here. Come back to that. Check to see if it's a battery issue. So what was what I was going to show maybe we're going to show it at the end. So basically when we fire this device up so you understand the risk is we can actually see the device out there. Obviously with Bluetooth low energy. But in a crowd like this I wouldn't know who was using that device. But if we look at the actual device the device has a couple things. It has a tracker ID. The tracker ID is the company identifier. It's like at four digit, zero, zero, zero, zero, whatever it is. And the MAC address is backwards. So that's the device identifier on this particular device. Also it doesn't have Bluetooth, BLE pairing properly. So I can pair with the device and set the alarm off remotely. So if you're in an audience and you identify someone using one of these tracker devices, bravo devices, you can set the alarm off and now you know who the person is because you look for that poor soul is trying not to look stupid as they try to figure out why their damn dongles buzzing and make an allowed noise. To go beyond that we moved from there and started looking at the cloud APIs. And it turned out that if we go out to the cloud API unauthenticated and pass that identifier out there we could get GPS coordinates of the user. So now not only can I identify who's in the audience with one of those devices I can proceed to track them at this point wherever they go. I don't know about you but to me that's somewhat of a serious issue. Now again you know I've had this conversation with media and stuff like that. We also got to put some kind of true risk behind it. If you're any if you're most of us and you have this device that risk would not be that big. Who wants to track me? And so it only becomes an issue is if you're somebody important you know you're a politician you know a movie star or something like that then it probably would have been a really bad idea. Or you have somebody that's a known stocker then it becomes more of an issue. But in generally it's I don't consider it the most critical issue but something that needs to be resolved. The vendor quickly resolved this issue right here. Now you have to be authenticated to be able to gain access to that. You can't read that particular data. I actually think in this case here they took that particular access to that API functionality out of the system so it is no longer viewable. So you change the battery on it? We'll look for it one more time if it's not there then there it is. So we can pair with the device a lot of times these type of connectivities and communications get messed up just based on the amount of Wi-Fi it's in the air so I mean it's still trying to pair with the device. So you go to a quiet room this works every time. I'm surprised any of this technology works with as many devices that are out there with all the noise. So that's thinking about pairing with it. So we're gonna actually move on. So the next device this is a panning button okay. So the story goes actual Associated Press came to us and goes the Colombian government South America has recommended that we purchase these for protection from being kidnapped. Okay and we really wonder is this a good solution? Is this a secure solution for moving forward? So very interesting project so it's like let's go ahead and take a look at it and see what's there. I mean we found a number of issues literally just a poor design a non-SSL communication some balance check problems within the functionality and some real time web server failures. So let's look at this. Let's start with the first total failure of the product. I didn't even have to open it up I just opened up the manual. So we opened up the manual we found out this thing where this device works it's configured and controlled via SMS messages. So you can set a password on this device a pass pin number that would add some level of security against the device from someone able to get your GPS coordinates and mess with the device except for one command. There's one command you do not have to have a passcode to gain access once it's configured. Guess which one it's the reset command. Reset the device back to factory level. It's basically you press the button it ain't calling nobody and I then can still send an SMS message to you because now there's no password and it's going to send back to me your GPS coordinates. Now if I'm in fear of being kidnapped that just with the hell in a handbasket real quick. So that was a vulnerability before we even open the device up. One other command they said didn't need a password was reboot. That was not true. Reboot would not work unless the passcode was actually put on the device. But we did find some use for a version of the reboot. Well it turned out that this particular command reboot all capital explanation point was a undocumented command. We pulled the firmware off the device and I went through the firmware and that's where I found that out. The interesting thing with that was it well anything anytime you send an SMS message to this thing and there is a password set on it you get no results back. So my theory was is there any way to war dial this thing or SMS messages thing. So we found out with the reboot it would return a format error. So instantly if I know all the reporters probably bought their phone from this location and they're in this city here and I wanted to gain access to the device or figure out who had devices. How hard would it be just to basically send an SMS message to every one of the phones and then wait for the response back and if I receive a format error response back the odds are pretty high it's going to be one of these devices. Given a stability to basically do kind of a war dial type of tack on the device. Moving from there we also found some bounds check issues. Didn't find an effective way to exploit these but it was still something to make note of. It turns out when you set up a command when you set up the phone numbers there's three phone numbers you can set up in this device and you use A and then the phone number B in the phone number and then C in the phone number. We found out that if you actually put more characters than what's in the phone number it would actually overwrite a segment of the configuration on the actual flash device. Now I didn't do this to all of the commands. The first time I did this I did it to one command and basically had to reboot the device like a dozen times and then send a reset message to it to get it even freaking work right properly after that. So I never did quite figure out what I overwrote but apparently overwrote something I shouldn't have. But as an example you can see here we send this command to set up the SMS message for the, or with SMS messages to set up the first phone number and we end up overwriting the second one B and you see all the A's show up in B showing to be able to overwrite that. Now there's a whole bunch of commands and I went into the flash and I mapped out the structure on the flash trying to find out if there was a possible way to overwrite some of the code. And I didn't initially find that so I don't think there was. It was getting pretty close to it in the flash to overwrite the actual firmware but it didn't quite hit it. The other thing was, and this was the actual web services and this was like totally bad. So without any authentication you can actually punch in the user IDs and this would return the phone's EMEI number which you could use later on to take over the device via the web application. So all you had to do was start at one and increment up over the 60, 70, 80,000 and basically gain access to all the identifier numbers for the actual devices. Another attack we were actually able to do using that EMEI number is you could actually poison the GPS data online. So literally once you've got that EMEI number you can make the device look like it was anywhere else on the face of the earth you want. So of course I did. So I live in Dayton, Ohio and instantly my device decided it was going to jump the Moscow. So we were actually able to poison and that would over, I'm trying to think of the port, it would over 2050 I think was the port that was actually open, completely open in the cloud, send all the data you want to it. Another potential attack point, you know what happens if I decide to send a number that's 40,000 characters long. I did not own the web server nor was I doing vulnerability testing for the web server. So in that case I was only able to focus on my particular data and the impact on my data. But again you're able to actually gain a level of access to that data which I thought was pretty cool. So let's check over here and see if the tracker device paired and it did not. Okay. It says it's pairing now. Okay that time it paired. Apparently it didn't like me clicking on it last time. So we actually were able to pair with the device. Now let's see if we're lucky enough to actually find it out there in NRF Connect. Okay here it is. Okay so now we can see there's a number of services on this particular device and we can come down here and based on the previous screen or you can see it at the top, unfortunately you can't. You can see the identifier. So we'll drop back to the other screen. For here you can easily just jump on alert. Go alert. Select it to high alert. Let's see if this demo fails like hell 10. Hope you can hear that. It's kind of high frequency. So you can see without any level authentication we could pair to the device and somebody's carrying and we could do generally what's taking place as a DOS is better and less long with it screaming like this. And I assure you the person is going to be digging through their stuff. This room's a little noisy but in most places coffee shops they're actually going to notice this fairly quick. There. Turn the alarm off. Let's come back here. Okay if we come down here to this device. Let me see. Ah it's already there. Don't do that. Okay so we can quickly see in here. Well I can see. I'm not sure if you can. I was hoping to have bigger screens but we can see the tracker ID here. So we have the four digits. Zero zero zero company identifier and then we have this identifier here. And this is the MAC address. So if you just reverse the MAC address you have the tracker identifier. And it gave us the ability to at that point once we've identified somebody with the device to continue tracking them as long as they own that device. And at bare minimum you're going to be able to track them to their home if you want to know where they're living. So a serious breach of privacy. A potential serious breach of privacy. Which I think is pretty serious. And I think this is closed in on the end of the presentation. There's my contact information. Please reach out to me. I'm always working on new stuff. I'm always looking for feedback, knowledge. You know I think in this field we're all kind of expanding and growing and learning new stuff. I've been doing some really cool stuff lately. Have some cool stuff coming out probably in the next couple months. I would say super great but some interesting again similar findings that really impact overall security of some of these products. Also some RF stuff we're messing with. And I've been doing a lot of stuff with actually data recovery off IoT devices. From being able to go in and pull the right chips and the right equipment and reading chips and doing some BGA and working on some BGA reballing techniques right now which is kind of exciting. Because every time I tear a device apart the last thing I want to do is throw it in a dumpster. I want to rebuild it and I've so far I'm pretty good at taking a device completely apart pulling the chips, pulling what I need and putting the devices back into place. But that's kind of the stuff I'm working on. Always looking for new ideas, new friends. So any questions? I guess not. Well I'll be around. Please feel free to grab me. If you have any questions you want to talk. Again thanks to the demo gods and my card dying on me.