 Ray, are you ready? I think I'm ready. Oh, Ray is ready. Let me introduce you, Ray, lockpinking in the IoT. Or while adding a Bluetooth low energy device, sometimes isn't a great idea. Here we go. OK, so welcome everybody to lockpicking in the IoT or the internet of things that will never be supposed to be on the internet. OK, yeah, there's a small overview of what we're doing. I'll introduce a little bit what is this about. Show you some hardware porn for the hardware lovers among you. Then look a bit deeper in the PCBs of that hardware for the electronics guys. Then we look into communication on the internet. So this is modern thing everybody wants to have in his coffee machine. And then we go for the wireless interface and see how difficult or not difficult it is to attack there. And last but not least, we will look into Android app hacking. I have to say, I'm mainly focusing on Android, but I'm pretty sure if you're more of the Apple guy, there are similar techniques available to go for your Apple app. But for most devices, they're supposed to, even if you're using iOS, you can hack the Android app to get the info. And then the talk is over. OK, the very important thing first, the disclaimer. Basically, I want to say, I just tested this on my locks. I don't say it's working and everything. I don't say it's a general mistake by somebody might have changed. I might be wrong. I just show my research. OK, this is basically what we're talking about. We have some kind of smart or not so smart device, which is talking over Bluetooth Low Energy to your smart or not so smart phone, which is usually talking using TLS and HTTP to the cloud. So it's not just locks. The talk is called lock picking because that's the thing we're actually going to attack. But the techniques here shown work for basically all of these Bluetooth Low Energy devices. There are, for example, different light bulbs. I found some interesting reports on light bulbs that don't use any form of authentication. So you can connect to your neighbor's light bulb and change a color or turn it on or off. So finally, blinking lights in your neighborhood. Then, of course, there's cars. Everybody's talking about cars today. I just heard the talk about cars. They're not really using Bluetooth Low Energy, but still they use an app and are controlled on the internet, so it's kind of on topic. Then there's vibrators. I mean, unsafe for cyber sex never has been easier. Actually, I don't have one of those. So if anybody has, please bring one over to play with it. But I'm pretty sure they have high-class security. And then there's button pushers. I just learned of that yesterday, and I thought, what's the fuck, a button pusher? This is the Bluetooth Low Energy device, which you can communicate to and make it press a button. Here it's pressing the delete key on my notebook. So finally, I have a Bluetooth LE-enabled delete key on my notebook. Very, very helpful. Of course, if you add that to your door opener at home, you can do it again lock-picking. We haven't hacked that yet because I just saw it yesterday, but it didn't look very encrypted. It has some secrets, some shared string we didn't understand, but possibly this Congress, we will look into it. OK, then there's cars. I'm not sure who read this message that Tesla had in big app hack. Nobody, oh, I thought everybody read it because it even was on hyzer. And it obviously is a very big vulnerability Alan Musk has to get better on this. And everybody's stealing these things. How are they called? Oh yeah, these smart cars. And they even have colors. So who wouldn't want to steal one of those? The bad news is actually that wasn't really a hack. What they showed is that the app is able to start the car. That's in the manual. So what they told is, yeah, but if I hack your phone, I can start your car. Then they realized, oh, you also need the password because for starting the car, the app actually asked for the password again. Yeah, but if I hack your phone, I can install in fake apps that ask for the password. And if you enter it, I can steal your car. Oh, surprise. I mean, this is not the kind of hacking we're talking about. And they then suggested the app should be more protected against reverse engineering. What would that change in this aspect? Can create a fake app without even decompiling the original one? So of course, if you don't have security on your phone working, if you install apps that are not secure, your data is not secure and your Teslas get stolen. But I didn't see anything in this hack actually being in a hack. So while talking about, bear your applause for this one, talking about obfuscation. That's really a thing some people understand differently than I do. I try to say people, security by obscurity does not work. So if you obfuscate your app, possibly it slows down researchers like us. But the people doing that for money who wants to sell exploits, they will still put their energy into it and sell their exploits even more expensive. And the exploit will even be longer out there because the independent researchers won't find the vulnerabilities at fast. The idea is good crypto does not have to be secret to be secure. So no, please don't obfuscate your apps better. Build your protocols better. But as I said before, I didn't see any aspects there in Tesla. Possibly they should make it obvious that you can start the car visit and make it disableable and what things like that, but it's not in security issue. OK, so let's go back to locks because actually the talk is called lock picking. So what do these smart locks usually do? Of course, they can be opened. Usually with your phone near your lock, you put something on the lock. It communicates the lock opens. Optionally, you have to press something on the phone. So it's a two-step process to unlock, which is actually a quite good idea because of some obvious scenarios which would work otherwise. Then, and this is different from normal locks, they can be shared to friends. It's a big feature they try to convince you why these smart locks are so smart. When I'm not at home, I can send somebody the code and give him the possibility to open my bike shed for just one hour because I can, of course, revoke that at time restrictions. So that's what the big advantage is compared to a traditional lock, except, of course, it's to be much more secure because you can't pick it anymore. And then those obviously have some fail-safe mode in case your phone breaks or whatever, you can enter a click code and can enter a code by some buttons or something to open it without the phone. But that is nothing we're going to look into today. So from these basic ideas, of course, there come some basic attack vectors. What I could try to do, I could try to bypass the sharing restrictions. So possibly go in a different time window, I could change the time on my phone probably, would that work, things like that, open the lock after it was revoked. Of course, then that's what everybody thinks about when talking about Bluetooth. I could try to get the keys from sniffing somebody's Bluetooth LE connection. That's something we're going to do today. Then this is what I was talking about why the two-button press is a good idea, you could relay opening codes. If you have the instant open feature, I could approach you, pretend to be your lock, your phone sends me an open command, I could relay it to your lock completely somewhere else, and it would open. So I think this is something you can't really stop except with some very tricky mechanisms, possibly timing or some things like that. So this instant open feature is possibly not the best idea. Then we have the option to attack the lock or app software directly. I mean, it's software, so it will have buffer overflows, it might have other weaknesses. It could just do not verify some things if I tell I'm another peer person, does it really check if I have the rights and everything. But this is something, I think the only thing I don't have in this talk today because the other message worked already. Okay, going to look at the hardware. So basically, if you're a lock picker or some other reverse engineer, if you get a new hardware, you want to take it apart. If you can't take it apart, you can't open it, you don't own it. And here's, if you want to do it yourself, these tips how to open it. The node is very nicely built when you have legally or legitimately unlocked your node, you can disassemble it without doing any damage to it. Just need a screwdriver and it completely comes apart. Very nice design. The master lock you have to drill out for rivets. So it's a bit sad because after that, it won't be a very good lock anymore, but it's not the problem because it isn't before from my experience. And then there's the dock and bone lock, which is a lock I just got recently. It's a little bit tricky to open, but you don't have to do a lot of damage. If you have it opened, you can pull out a pin in the back, thank the N for finding that out. And then you can remove screws and it really comes apart nicely. So how do these locks look now? This is the node. So basically you see a PCB, you see a normal lock body like here with a shackle. There's a motor at the PCB, the motor turns some locking element in here and if it's in the right position, the lock opens. For the nodes, there's a very nice paper by the SSDef member, Michael Hüpler. I have a link at the end of the presentation. And neither he nor me did find any mechanical bypasses for that lock. So the mechanics look okay. Then there's the master lock, it's very similar, but I have to say they invented this mechanism with the motor and this locking element first. It has four buttons on the PCB, which you can use to enter a code. It has two CPUs, pretty standard design and here are the rivets you have to drill out to make it open. The docking bone is a little bit more clumsy. It's a bigger lock. It comes apart in quite some pieces. What I really liked was that motor with that gearbox. I think it's like one, two, two thousand or something. So it really gets a lot of power from the very small motor. So what does it do with it? It turns this element and this element retracts these two spring-loaded locking elements which are locking the shackle. If you're a lock picker, you will ask spring-loaded? Seriously? Have you ever heard about the term shimming a lock? Shimming a lock is inserting some metal at the shackle and pushing back the springs. It's a very standard method for padlocks in the $5 range, I would say. Locks starting at $10 to $15 or euros or whatever in that area usually can't be shimmed anymore. When I opened the docking bone lock, I instantly realized it's spring-loaded. It's shimmable. A short search on Google found out that Mr. Locksmith, lock picker from the US who does some YouTube videos, found out months before. And of course, it's shimmable. You put in some thin metal sheets, he builds them from a cutaway of a soda can, puts them in and the lock opens. But this is not the $5 lock. This is an $80 to $100 Bluetooth padlock. And you shim it with cut metal. Okay, no need to go into the Bluetooth low energy for that one. And as a small teaser, I also didn't say there's no mechanical bypass for the master locks, but we'll come back to that. Okay, the electronics. This is the electronics of the nook. Basically you see there's one CPU and something that's called an H-bridge which is used to control a motor. All the rest is pretty standard electronics. So very simple design. The master lock has two CPUs, has the buttons on the PCB, also quite simple electronics. And this is the MCU. The interesting thing I see is there's a very common ship. It's a Nordic NRF 51-822. I find it basically everywhere. It's in light bulbs, it's in three of the locks I have here. Or four, if you count the evasion and NAS lock as the same. Only the master lock uses the MSP430, which is a, the NRF is a basically ARM core. The MSP430 is a much smaller chip. It's from Texas Instruments and it's a very low power consumption chip. It was also used in the previous non-Bluetooth LE electronic lock. But it's basically also a normal microcontroller and you can program it. So program it. That means you can just use any ARM flash board. I used the ST-Link interface from an STM32 dev board. We had an hour hacker space and interfaced it to the chip of the NOCLE padlock here. So for example, using OpenOCD, but there are different tool chains, but this is one where you find some info on the internet how to use it with the NRF. Using OpenOCD, you get an interface to connect to the chip and then you can issue commands like probe the flash in it. You could read the flash. You could write a new firmware to it and stuff like that. With the old master dial speed padlock, which is pre-Bluetooth LE, but already electronic, a few years ago, I think four years ago, we presented about that one. That was not re-protected. You could change the firmware. You could actually get the codes from reading the flash and you could access the flash contact without opening the lock. So that was very funny. Not usable as a lock, but I refreshed it to a Simon Sestai game where you have to repeat the sequence. It shows you funny lock for your hacker space. Unfortunately, or fortunately, no, I would say unfortunately, the NOCLE firmware was re-protected because there's no need for it. The NOCLE firmware flash points can't be accessed without opening the lock. So you don't lock somebody out by flash by re-protecting it, except for the legitimate owner. But okay, it was re-protected and I was saying, oh, decompiling firmware, that's hard work anyway. Let's skip that one. But of course, you could use these flash interfaces to write own firmware to these locks, possibly make them open source one day or do something else or just use them as cool dev boards with some actors on it. So let's go for the first interesting thing I would say. The communication with the cloud. Yeah, so your phone speaks to some service which is provided by the vendor of your hardware, usually. And it's usually a TLS encrypted link using HTTP. Over this link, the application on your phone sends lock-in data, gets back from the cloud's information about the lock so you can install your app on a new phone, enter your locking credentials, and instantly use all your locks or the locks that were shared to you. Usually these apps also send events to the cloud when you open your lock. So if you share the lock with someone, you can see on your other phone that he opened it and possibly where he opened it and things like that. And of course, also data is edited if you add a new code to it or something, this is sent over the link. So some people would say, oh, but TLS encryption is secure, isn't it? Of course, usually it is. There are flaws which you hear about from time to time at these conferences, but that's not the problem here. The problem is, but it's not a problem, it's nice for us researchers. You own the phone with the app. You control the app. You can even modify the app, but owning the phone, you control the TLS trustor with the certificate authorities. So you can install a new CA and trust your own servers. People could try to prevent this using key pinning in the app, but again, you also control the app. You can change the app, you can remove the key pinning. So basically breaking into this TLS is something the vendor has to expect. It's your device, it's your communication, you can listen to it. So and the nice thing, and this is what I'm trying to tell all of you here in this talk, these things are not difficult. There are nice available tools and if you have some apps which do some things you want to know, install such a tool, watch your app doing transferring data and look what your apps actually communicate. Actually, it's quite interesting to see what your phone communicates to Google all the time. I realized that one of these apps is telling Facebook when I started every time, what's the fuck? But you easily see it. What you do is you install, for example, Mitten Proxy, it's a small hell of Python dependencies, but it's usually installable on a Linux and even on a Mac machine. Haven't tried it on Windows, but I'm pretty sure there's options for that. And you install it as a web proxy. So you change the internet connection of your phone and say, oh, this Wi-Fi has to use a proxy, enter the IP of your proxy. And Mitten Proxy creates fake certificates on the fly. So whatever site you access, it creates a new certificate looking the same, signs it with the fake CA. And you can install the fake CA just by going to Mittenmit. So man in the middle it and there's a link to install a fake CA on your phone. So that's actually really in like five to 10 minutes with compiling of supplies and stuff, 15 minutes and you have a working man in the middle set up and can watch your communication. This is what the app looks like. So we see here a few post requests to the NOG app. We get replies. Actually, we see funny four or three's here. I don't sure why it's doing that, but okay. But this is what the NOG app does on startup. And of course, we cannot just see the requests. We can look into the request itself. And it's, for example, a good way to recover your password. Possibly I should have blurred it here. So if you have forgotten your password, you just sniff the communication. It also works for your Play Store password usually. Usually they use a token, but sometime it's renewed. So every app that has a password and sends it to the cloud, you can recover it with that. And from this login, you get data back. And in the NOG app, it's usually done like I send lock in with user and password and they get a token back. And then all following requests, I just have to send this token and then I'm authenticated. So that's an okay mechanism, I would say. So what do we get also? We get have a get locks key. And when we call get locks, we get the information about our locks. So this basically is an ID of the lock. This is a lock key. This is something to remember. 0137, we'll see that later. You see the Mac of the lock. You see a picture all where the application shows me the lock. If I have multiple locks, I can assign different pictures to it. And this is a quick link, a quick open code where I can push on the shackle to open this lock. So this is all no hacking because this data I'm supposed to know. It's my lock, I can know the information, then it's not a big problem. But it's interesting to see what it's doing to understand how it's working. Then we have the next thing, the shared locks. This is more interesting possibly because I see, oh, I'm allowed to use it all day, starting at that day, starting at the time, ending at that date, at that time. And this lock has a key and this is another key and has another Mac. So the nice thing is the lock does not have a time. The lock does not know when I'm allowed to open it. So all I need is this key. And the nice thing also is I don't have to manipulate the app in any way. I can use Mitten Proxy to change the data on the fly. So I just tell Mitten Proxy, please change 2016 to 2066 when the reply comes back and then the node up thinks, oh, he's still allowed to use that. Of course the node people were clever and do an online check, which actually means you can only unlock a lock which is if you have a shared lock, your own lock you can use offline, but the shared lock you can only use when you have internet, not good if it's a seller or something. But it does an online check, it asks can unlock and the cloud answers, yes, success can unlock. Of course I can also fake that. So this is completely bogus. It's unnecessary to be online. I could do it offline. If I want to hack the lock, I can do it in the seller. Only the legitimate user has to be online. So the sharing feature of the node already is broken just with the Mitten Proxy tool. And it's really, that's not big hacking. They could have thought about that, but okay. So once somebody shares a lock to you, a node to you, you will have this key and you can use this key from then forever on. Using the original app, that's a nice thing. You don't have to change it. One thing which is positive about the architecture here, the key that they use for sharing is a different key than you have to operate your lock. That means with this sharing key, I cannot modify the lock. I can't rekey it or change the click code or things like that. So I just can open it. And they have an option to change the key of the lock. So I can go to my lock and say rekey and then they do a new key. But for that I have to go to my lock. So that's nothing if I share the lock to you from Congress and the lock is somewhere in Salzburg, then it doesn't work. So not really helping. Possibly one time keys or something like that would be a better option or just some challenge response mechanism if you have to be online, why not? But that's something for the future. Currently lock sharing is not very secure and I would advise you to keep that in mind when you use the sharing feature. Oh, regarding dumping firmware. As I said before, firmware was not dumpable from the nook. The docking bone, I didn't even try to dump the firmware because it was shimmable, but they sent me a new URL in the connect where I can download a firmware. And if you, again, I don't consider this a vulnerability. I think if I own the lock, I should be allowed to read the firmware. If you download that, it's an actual hex dump of the firmware it looks like directly what you would flash on the chip. So if you want to do some firmware reverse engineering, that's a very easy starting point to get a firmware from the internet. Disassemble it, play with it, flash it possibly to your own deathboard without even owning the lock to play with it. Why not? Okay, so so much for the app communication. You can do quite a lot with it already, but we want to go a little deeper. We want to go for the Bluetooth Low Energy level. So the communication between my phone and my lock or my vibrator or whatever. So Bluetooth Low Energy is newer but actually easier to sniff than Bluetooth. There's a talk called this Low Energy comes low security if you want to have an introduction to that you find it on YouTube. Basically, it has three security modes, but the most common used are non and ad hoc, which is like almost non security. And the third one would be pairing with a code which is usually a six digit number. If you listen to that pairing, you also own everything. This improve this Bluetooth Low Energy 4.2 which includes the new Low Energy standard, but this is not implemented very commonly today and won't be in the very near future because not so many devices support it. So for now, Bluetooth Low Energy is an easy target to get into research. Just available tools for it like the UberTools one by Mac Osman, the other through BTLE Sniffer for very cheap. And you can build your own one by flashing a firmware available from Nordic directly to any dev board with this chip you have. So this is the hacker space entry point if you have the stuff lying around. Otherwise, I would recommend going for the other through Sniffer. It's orderable even in Euro very easily, so not a big problem. But the very cheap option is get a three to five Euro dev board like this from China. Use your STM32 programmer. I have another board here which is in serial interface, but you could use your normal FTDI, USB to serial also. And then this board is identical to the other fruit, Bluetooth and eSniffer for like five bucks. Okay, talking about this research, this is nothing nobody did before. Somebody like for example, Rose Ramsey did it at Defcon and presented quite a nice talk where he analyzed a lot of locks. He had like 15 locks of it and 12 of them broken. So it was really plain text passwords on the Bluetooth LE for the quick lock, I blue lock, blunt through phantom lock. I hope that's correct. I don't claim this to be true, but he told in the talk. He found replay attacks on these locks, so you can just resend the same code that you saw before even without understanding it. But he stopped where it became interesting and instead of that posted this slide, which I hate. He wrote about uncracked locks and the first one was the no padlock. And for the timeline, at that point, I already had this closed to know our findings which you will see today. So the no company knew about their lock being completely broken on the crypto layer, but they see this talk by Rose Ramsey and post a block post. No, just one of the few Bluetooth locks to pass hacker testing. Seriously, they were notified and we had active communication about they changing the crypto protocol. Possibly the social network people are not so close with the technical people. But okay, so let's crack it. Using the Nordic Bluetooth Ali sniffer firmware, which is unfortunately the easiest way to use it on Windows, but you can use it with Python also on Linux, the wire shark integration isn't that nice. So if you have a Windows or Windows 3M, it's the more easy entry point. Here you have a text interface where you say I want to sniff to this device. Then you've got a lot of packets here, mostly discover, discover, discover. You have to look for the bigger packets. This was the bigger packet with some payload and it contains a very long string which looks completely random. So I see from phone to no access random from no two phones as random looks actually encrypted and no is claiming they are using AES 128. So I didn't even try to understand what I see here because if it's AES encrypted, you won't find any meaning in it. So let's put the sniffing aside for a moment. We can sniff to the data. We can get this communication off the air, but for the no, we can't do anything with that. So let's go for app hacking. There are different approaches. One of the easiest, no, not the easiest, but the first one we did is manipulating the apps. So you can get an APK from your phone very easily with ADB. You don't have to have a rooted device for that. You can just enable devil mode and copy the APK over. There's lots of tutorials on the internet how to do it with basically three calls on the shell. And those APKs can easily be disassembled with a tool like Smali. You can change things in it like in URL. You can change values. Then you can reassemble itself, sign it and put it again on your phone. One thing you can do with that is change the app to use a different URL for its communication. And that's actually quite a nice idea because we saw before we can completely understand this protocol. It's not a complicated protocol. It's sending some requests. It's getting some JSON responses. I can write this in a Python script with a few hundred lines and fake their server. So I actually could run my no-clock if it would be having good crypto, but okay. On my own server, not connected to the cloud but build my own no-cap and have it communicate with my no-c server. Why not? Possibly in the far future, no-c doesn't exist anymore. Who knows? It happened before to other companies. The servers are gone. Your hardware is gone. If you understand the protocol, if you have sniffed it before, you can reimplement it and continue using your hardware. Except for that, I wouldn't like to have my locks in the cloud. We actually used this method during the analysis of the no-clock to change a random number generator in the app to always return 42. Thanks to SAC for that one. He did a binary patch on the MIPS binary on it. We just put it in and had a nice random number to spot it easier on the communication. The other thing is you can decompile these app APKs. You get it again with ADB. Run it through a decompiler like JetX, which you can install on your PC. You can download it from GitHub. Or if you just want an easy decompile, you go to an online decompilation service. They say, please only use for legitimate purposes, but we do. And yesterday, SAC was very annoyed by the ad blocker blocker they have. But if you ignore that, then it's very easy to just upload an APK, get back the source code. And then basically we have Java source, which you can read, you can search, you can grab. Oh, you can grab. So we were looking for AES. Yeah, everybody is laughing at this slide. But there's two things to mention. First of all, this is not all of our research. This is just the beginning. Then it became difficult. The other thing is this key, of course, is very silly. They actually use 0, 1, 2, 15 as in AES encryption key. But if they would have used a real random pre-shared key, I still would have found it that way. So actually it's not really less secure. It's just possibly left over from development. I have no idea why you would use that key. But still, even a better key, I would have found it in the source code because it's a pre-shared key, the lock knows it, the app knows it, has to know it because it's pre-shared. So yeah, but still it's very funny that they have this silly key in there. And we were actually wondering quite a lot how, but what block chaining mode do they use? How do they use AES? Is there an initialization vector? I don't know. Took us quite a while until we realized it's simple, just one block. If we use the thing that we sniffed earlier and just run one AES decryption with the key 0, 0, 0, 1, and so on, we get something which includes our 42 numbers. Oh, our random numbers turn up. How are the chances for that? No, so actually this key decrypted the thing we got from the wire. So we thought success in locust cracked. Unfortunately it only worked for the first two messages and all we saw in these two messages is our random number and the answer another obviously real random number because we didn't patch the lock. The next messages from that on again were completely scrambled. So we had to do some more reverse engineering. Unfortunately, or fortunately to make it a little more interesting for us, this APK from Nook doesn't only include the Java source. It has some shared object files. So binaries which are compiled with some other compiler probably see. Luckily those were in there for Android for multiple architectures and one of those I don't know who is using Android on x86 but obviously it exists. So we had all the libraries also in x86 which we could run through a commonly available disassembler I started doing this object dump and things a little bit but it's really hard to read and you don't come so far with it. So big thanks again to Sec and to E7P who helped me a lot during Easter Hacks this year which was a quite nice event where we did some lock hacking and they were staring with me at either pro dumps all the time to find the key exchange and finally it worked out. So all the assembler is very hard to read I think but we see there's a parseCMD function we found actually they had the labels in there which again is not a vulnerability it just made it easier for us to spot the stuff. I don't think that's bad from them it's okay. So we found this parseCMD it actually calls an AES decrypt function. It gets a little bigger and bigger and bigger. So we find and I actually can't read it from here very good but this was the create session key. Yeah this is sounds very promising it was called create session key. Might have to do something to do with the things we saw before and it has this inner loop and this loop is actually something people could understand if they can read some x86 assembler. It's a loop of four iterations and it's x oring values from one area to another. So it's basically x oring four values and this is the core component of the key exchange. This is the four byte numbers that we saw earlier my 42, 42, 42, 42 and the other one coming from the lock are x or together and then there's some more magic done. So basically the app sends a random number to the lock the lock sends a random number to the app and from that there's a session key calculated by adding x or of these two numbers to the middle of the original key. So you have this original key that we saw before and you add this result onto it. So we saw from the app our 42, 44, 42. Of course if you have the real app running that would be still real random but it doesn't make a difference. It just was easier for us to see it's the same every time so it helped a little bit but not too much. So the lock sends a key. Those two values are x or together and then they are added onto this silly pre-shared key. I don't know why they're doing that. I mean they could have at least added it to different parts of it and they would have more entropy in it or I'm not sure who sits in the cell and does some coding and thinks this is a good key exchange. You can't really look into these minds. But okay so we can do something in our head. We see here is FD. We add five to it so it rolls over. This is why it's a modulo operation and get a O2. We have BB here. We add six to BB. If you can calculate hex you'll see it comes to C1 and so on. So everything that changed in the key is the middle four bytes. Which is actually another vulnerability because it means even if for some reason which I really can't imagine because this exchange is done every time you open your lock. It's not something done on the first time or done once per phone or something. Every time somebody opens this note this whole sequence is run through. It connects to the lock, sends a random number, receives a random number. The session key is calculated and using the new session key the rest of the communication is done. But just in case you did miss the first package for some reason. If you have a real attack scenario where you can't replay it it might happen that it's scrambled. Then it's still four bytes changed in the key so you can brute force the new key by knowing the old one and brute forcing those four bytes. So I think that's doable on a modern machine without bigger problem. So really not the cleverest key exchange but even if it would be better it wouldn't really help because there's no asymmetric crypto in it just nothing preventing us from following it. If you exchange a session key over a pre-shared secret somebody knowing the pre-shared secret will always be able to follow it. So they have to do some big changes there to make it proof against sniffing. So we have this new session key and of course they have to verify what is happening. So we have the next message which we have from our wire. The decoding is with a new very cool key we have and we get something that doesn't look completely random. We do it with multiple ones and see some structure in it. It's always, I'm really, I think I've pasted the wrong thing here actually very sorry for that. You have to imagine a different message here encrypt that using that key and you would see what would be up here. But here would be this random we got from the air we decrypted with that and get this and this dissects into an opcode which is always at the third byte. And after the opcode we actually see the lock key which you remember from one of the first slides. Oh, one, three, seven, five, five. This is the key from my lock. So we now got the key from the air and have full access to the lock. Bad luck for no. So, oh, six is just one of the opcodes when you browse through the Java source you see much more opcodes that might happen. So for example, there's the rekey option which you send to the lock and the lock starts to rekey, to regenerate the keys, send back the new keys. You can unlock which is what we just saw, get the battery level, set a new quick opening code, can reset the lock, can do infirmware update. That looks promising. I have the idea we will see this opcode in the near future and you can enable key fobs which are small devices which you can use to open the lock without a phone. So you can send commands to pair those and add them and get locks of it. So this is just a few, we haven't played with all of them, the set quick code I think I sniffed a few. Yeah, but that's basically the things you can do and you can decode all of them with the message shown before. So some history of the vendor notification. We did this on the Easter hack, everybody knows Easter hack is Easter. So this was in April. Possibly wasn't the best idea to send them on April 1st, but no, they replied and took it seriously. So they actually very instantly told us they liked the research and everything. They knew their crypto isn't perfect, but the product has to get out and they were working in new protocols. They sent a few details of that. We don't have full details so far, so we can't really tell if the new protocol is very good, but it looked from the idea a little better. They're bringing out a bike you lock which is not out yet and it's supposed to have the new protocol from shipping, we will see. The thing which I found very funny is I downloaded a new app in November and it has a major update in the screen. The rekey button is now hidden. So remember that the only button which saves you from someone you shared a lock to lock him out. So this button now is hidden. Possibly not the best idea. Possibly people weren't understanding it, but it can be enabled into advanced settings menu so no problem. But they just recently told me that they're planning to actually fix that in January. So we're actually really a little zero day here so the locks are still vulnerable, but eight months, sorry. The conference is now, we couldn't change that. So if you use such a no clock, I still want to say, I like the hardware. It's quite a nice hardware, possibly write an open source framework for it, build your own crypto during the time or just don't use it for real valuable things or use your Aluburka or other shielding while opening it, I don't know, but just be aware if someone sniffs your communication using his $5 deaf board, he probably knows your codes. So yeah, so much for the no clock. This is not really the end, it's just the beginning of the end section because we still have one mechanical bypass left. Remember that earlier I mentioned also the master lock doesn't have no mechanical bypass that we found. If you remember chaos communication Congress four years ago, you can remember from the rocket standing exactly here, we did a presentation on this first Bluetooth, not Bluetooth on this first electronic padlock by master lock where we had a nice mechanical magnet attack which was found by Michael Hübler by very cleverly drilling a hole observing the motors acting as magnets and found this special move which opens the old master lock. So did say, and we reported that back then. So four years ago we told master lock, oh, your padlock can be opened with a magnet. This is not very good, but this was a $30 padlock and oh my God, could be done with a magnet. So this is a new one and they changed something. Actually it's something they told us back then that they're planning to do. They added a shielding metal. So this very big, thick shielding here which I would use to block all the radiation from whatever it is. Around half of the motor is supposed to help. Let's have a look. So this is the master lock. We have a bigger magnet. I have to admit you see it's a much bigger magnet. Those magnets are illegal to possess all over Germany, I hope, soon. And we have a different move. We're now rotating the magnet. We were shifting it before. And it's open. This also is not really zero day because as you saw before on the slide by Ramzee, he also told the master lock is unpickable. And after the talk at DEFCON, in the Q and A section somehow mentioned that I doubt that. I didn't tell what to do exactly because I wanted to give master lock some response time, but directly after the talk, somebody approached me. That's very interesting. I'm with master lock. And I actually showed him this and he filmed this with his mobile phone. So I consider the vendor notified. So I would say works for me. So I have a message to all these vendors and kick starters and lock makers. Don't try to be smart. And disclose your crypto protocols. There's really no need to make a secret crypto protocol. And if your development department tells you, no, no, we can't disclose that. That's a really silly idea to disclose our crypto. You probably have bad crypto and they know it. And of course, if you build a new thing like a hardware like a lock, for example, try to get your hardware in the hands of experienced lock pickers or locksmiths. The shimming bypass of the dock and bone padlock, really, every locksmith in the US would have told them, you can't build a hundred dollar padlock which can be shimmed with a soda can. And especially if you're an electronics company, what those dock and bone people obviously are. Don't trust on your electronics knowledge. The hardware also has to work. And please, if you give this hardware to people, don't try to get any NDAs or oh, you can't disclose. Because then they won't do it and will wait just for the product to come out and disassemble it then. So really, actually I must say there were no people, which, yeah, the lock isn't working that good, but I think the company is doing quite well. They sent us one of their locks for mechanical analysis after our master lock presentation. So we tested their lock on our magnetic attack and that didn't work and still doesn't work. So that's the thing they did good. The other thing is that they didn't get the crypto right. But okay, people are learning. So if someone really wants to be smart and we also try to tell that no in the Kickstarter campaign, try to become the first one. And this is really what's the fuck? Why is there no at all open source lock or light bulb or vibrator? I have no idea. But I think you want to sell the hardware. Why don't make the software open source and make it audible? Oops, what's that slide? Oh yeah, that's hackagepity. If you want hackagepity to happen next year, please send content. I heard from that sex guy and that dry guy that they're really old and they don't know the things that the young generation wants to have asked in a jeopardy and what documents you have to ask and stuff like that. So send a few ideas. There's a German page, but hackagepity will be German next year. So sorry for that. A German page which tells you how to submit ideas, how to make good ideas. And if you send enough content possibly next year, there will be hackagepity again. So we have some links. Actually, this is the zero day tool we are releasing by E7P. It's not on there yet, I think, or possibly he's sitting in the audience and uploading it right now. It's a small Python script. It needs Python 3. And it implements this crypto session exchange. So what you basically do is you get the values from your wire shark, which is all these hex strings, puts them to a file, starts the decode node tool, and it will tell you what key code is in there, what things are set. Currently, it only supports, I think, the open command, mainly in the read battery possibly. But we'll try to add a few more codes as we decode them. But it's enough to get the lock code from the error. So with this tool, but you could implement it yourself, you easily can crack the locks. So there's a block entry by MH who did a nice paper about the node's hardware and everything. If you really want to look inside the lock, look at this. And then just, of course, the link to the Nordic RF sniffer software. This is one of the decompilers which is actually add blocker, blocker on it. And there's an article from Sex Block telling you how to decompile and recompile an app, which I found quite helpful during the working. So, okay, so thanks for listening. Please, if you have smart things around and want to play with that, I have one of these dev boards left. So I have two one for me and one I can lend to somebody who wants to sniff to his hardware. Come to the new CCC assembly and tell me what you want to attack and I'll give you my RF sniffer board. Or leave the things there and replay during Congress. Not today possibly, but tomorrow I will be in assembly or someone will be there. And I think now I have basically exactly 10 minutes and I hope there are some questions. Otherwise, I was too quick. Thank you. He wants a microphone for the questions. And it's for the answer. Ray, thank you very much. Do you have some time later? I might need to ask a favor. Did I told you about that friend that I'm having with the Bluetooth enabled coffee machine? We speak later. We have some questions and we have some questions from the internet. So here we go. Yes, thank you. Ray, are you aware of any secure Bluetooth locks with decent crypto? Actually, not. What I can't tell is if the crypto of the Master Lock or the crypto of the Dock and Bone are good because we really haven't looked into it, but it wouldn't really help because their hardware is broken. The NOC people, as I said, are bringing out a new firmware in January. I'll try to make them tell me what they're doing because I'm not really going to reverse engineer it again. I'd do that for a render once. We don't have to do it a second time so I hope they just tell me what they're doing and we can have a look if it looks promising. But at least they react. So possibly the NOC is becoming a more secure padlock, but besides that, I don't know any so far. You can find the talk by Rose Ramsey on the internet. It's unusual for DEF CON talks, but this DEF CON talk is online. So you see lots of locks there which he attacked and they all were worse than the ones we had here. So sorry, NOC, which I could recommend. And I wouldn't recommend it anyway because if it's not open source, you don't know if it's secure. You just know it's currently uncracked. So possibly stick through your old ones. But thanks for the question. Then we're going to hop over to microphone number two. Thank you. That was quite a bit of French aiming, fun talk. Just one thought. You said that it's about sewing the hardware. Well, maybe it's not because from what I understand, most of those devices are cloud enabled. So I'm pretty sure they collect all the data and maybe it's about mining that for them. I don't know. Actually, yes. The NOC has a pro version where they sell a company license where you can have a company software to the cloud and have more features like sharing all those locks. But still you can make it open source and make a license that this allows commercial use or something like that. Open source doesn't have to mean it's free to use. And if you have very complicated logic for your company portal or something, possibly keeps that closed source, but enable me to follow your communication to understand how keys are generated and stuff like that. This is not your secret. This is something, this is the elementary function. People should be able to understand and audit. And especially in a commercial environment, if you ask a locksmith or some other security expert, would you recommend this device? If he can't look into it, he can't recommend it. So I think also for selling appliances or selling services, open source algorithms, open source protocols would be the best solution. But especially in the lock industry, that's very, very uncommon. I had really bad experience talking to normal lock manufacturers about open sourcing and stuff. It's an idea they don't understand. They're about secrets. I don't know. Let's hope for the future. Another? Okay, yeah, we had, number one is just coming up. He was queuing at three, but covering the camera. And then the cameraman got a little bit disturbed. And it's a long story. One we go. I was wondering if you knew about any locks which advertise their existence, like broadcasts, things like that. Could you walk through the street and know there are Bluetooth locks around you? No, those locks usually don't broadcast because it would use too much energy. So usually you have to push the shackle of the lock or something, and then it broadcasts. There are actually, if you go back to the Stefan talk I was talking about, and I think there's enough shaming of master lock here, if he has door locks and stuff like that, those possibly are connected to power and advertise all the time. So he did some lock wall driving, but for the padlocks, that doesn't work. But of course you can go and click them and then get the idea. And of course you can do the other thing. You could walk around and pretend you're a lock and see if someone has the app running and connects back to you. That might work. And over to microphone number two, please. Yeah, I was wondering about that strong encryption, meaning AES, and on the other hand, the very weak or vulnerable or flawed key exchange. Do you think that might be due to outtasking, like they have specified that they want encryption and have not specified how key exchange is to be handled and that might be the reason why it takes them eight months or more to fix that? This is basically two questions. Of course I can only speculate. It might be outtasking. It might also be that they just had the time. If you follow the no Kickstarter campaign, it was all funded in the Kickstarter, they had a lot of problem in delivering on time. There's lots of comments. I'm waiting for my lock. Oh, God, another delay. Now you're claiming manufacturing is difficult, so many, many people saying you have to come out with that. So it might be time pressure. It might be outtasking. And of course it might be that they are specified how we want to use AES. And that's the other thing. Everybody says, we just closed what we're using. We're using AES. You have a very good example. Yes, it really is using AES. And it's using a correct implementation. We actually found it's a TI example implementation of AES that they're using. So it's completely valid AES 128, but still it's completely insecure. So people just claiming they're using AES or we're using Shah something or something. Isn't enough? You have to know the whole protocol. And that wasn't the case here. OK, then we're going to go over to the internet again. The internet of. Thank you. Actually, it's a follow up question for the previous one. Would it be sufficient to have a hardware accelerated AES on these Bluetooth thingies? Actually, hardware accelerated AES doesn't have to do anything with that. There might be helpful if you have a chip which is a crypto chip, if you have things like side channel attacks. If you would have a key fob which has a secret key in it which should not be extractable, those keys can be extracted with electronic attacks, side channel attacks, power measurements. Again, these attacks, a crypto chip could help because it has a good implementation. But for this AES is AES. As I said, the implementation of AES is valid. So an accelerated chip wouldn't help. And they're not doing bad crypto for performance reasons. It's only one AES operation. They're doing it because it's more difficult to do it right and it possibly would need asymmetric crypto. That could need acceleration on the other hand, but it doesn't have to do with a chip. Are you queuing there on five? Well, then here we go. OK, two little questions, more hardware related. First one, how could you build a lock which isn't susceptible to the attack you showed in the video, like flipping the magnet? That's the one. And the second one is that Trelok or Aebus, I think, says they have an electronic bike lock which doesn't have any battery. And I'm quite confused how they would do it. Have you had any idea? Actually, I don't know the, starting with the second question, I don't know the Aebus lock at all, I must admit. But there are, for example, also CyberLock, is it called? They have battery in the key and you put the key to it. If it's a Bluetooth lock, I don't know how they're doing it. It might be possible that you push something and it starts in generator. I've seen buttons which you press and they generate the energy to send while you press it. So it might be that, but I don't know the product. The other question I must admit, I didn't really understand what you want to know. Can you repeat the first one? Of course. I was just asking how to protect the lock, so it can't be opened by flipping a magnet like you did in the video. How to protect it, that's a very good question. I think we know how NOC did it. And the thing is, I don't think NOC did it intentionally. It just happened to be in their design. We can't open the NOC because the rotating actor they have is also magnetic. So if I put my magnet there, I lock the lock. In the master lock, it's some cast metal which is not magnetic. So changing this to magnetic would possibly help. Using a completely different approach like the motor in the quick lock, or which needs more power or works differently like a server would help, but would be a completely different design. But it's really a tricky part. They have lots of locks in the past. Also door locks being attackable by hardware attacks. So building a good, really good electric mechanic isn't easy. And I think we have time for the last one at microphone 5. So this isn't a question. It's just a precision. At one point during the presentation you talked about open source smart appliances. And you said, nobody really does that. And you urge people to be the first to do, for example, open source sex ties. And it happens that someone is doing that. So on GitHub, it's Q dots. If you want to learn more about what they're doing, they have several public repositories about teladildonics. So if anyone wants to check that out, just saying. OK, thanks for your self-advertisement. And I was mainly talking about locks, I must admit. I don't know the other fields so well. But locks is really difficult to get open source. If you have more questions, I'll be at the new CCC assembly. I'm waiting for you to bring devices, get the deaf board, hack the stuff, and thanks again for listening.