 My name is Justin Engler. I'm a senior security engineer at ISEC partners. This is Paul Vines. He's a security engineering intern for us for the summer. We both work for ISEC partners and we are here to talk about automated pin cracking. We will talk about R2B2 which you can see here moving on the stage. You won't see C3BO and we will talk about why. So quickly we're going to go over what your approach would be if you need to brute force something like this. We're going to talk about the robots we built to do it in specific and then we're going to talk about countermeasures and how the robots stack up against countermeasures. So everyone here know what a pin is? Anyone never heard of a pin? Okay, good. So if you need to get into something that has pin protection, so bypass whatever the pin is blocking you from doing, you have a few options. One, you could do a software approach where maybe you jailbreak the device, maybe you have a jailbroken device and you hack the app so it removes the protection. This would be your best plan. It's usually quicker, it's usually more direct route to do what you want to do. If for some reason you can't do the software approach, your next best option would be a hardware attack. Our example here is keyboard emulation. Darren Kitchen at hat five has a neat video where he plugs in a USB rubber ducky into an Android device and does something similar to what we're doing here. So that would be great. Other hardware attacks are also a good second choice so maybe you can pull the RAM and read it or things like that. The last thing you should try to do if you have no other options is to brute force the UI itself which is what we're doing. I'm a security consultant so I often work on engagements that have a set time period and I don't have time to sit and brute force out of pen it would take too long when I'm supposed to be doing other things. So the next option is to get an intern to do the button pushing for you. So you could have an intern just sit and push the buttons but sometimes interns do things wrong and we don't really have any way to guarantee that the intern gets it right. My boss Andrew really loves his coffee and if I take the intern to push buttons all the time he won't be able to get any coffee and I don't want to get fired for that. So a much better plan is to hire an intern and have him help you build the robot that will push the buttons and then he'll still have time for coffee later. So in order to build a robot to crack a pin you have a few things you need to be able to do. Somehow you need to be able to actuate the interface so you're going to need to make the device think that the button was pushed. You're going to have to keep track of where you are on the list of all the pins and you need to usually figure out whether you are successful or not. There are some cases where you just need the device open and you don't care what the pin was. So in that case you could do something even simpler than what we're doing. Just have it run through them all and keep going after that by the time you come back after you went away for the weekend or whatever then the device should still be unlocked because somebody's still been hitting the screen the whole time and you're in but you don't know what the actual pin was. We are doing a little better than that. So this thing is a Delta robot. That's the general class of robot that this is. Delta robots were originally for industrial work in the 80s are still used for that stuff today. There's a few rotational motors that through some math that we'll talk about later can turn rotational movement into X, Y and Z movement. It's also very fast but it doesn't have a lot of torque or a lot of lifting power but we don't care about those things. So this seemed like a good choice for us. And I said it's fairly simple to do the math but there are a lot of math involved. I set Kazone by NCC group which is a company in the UK so math are plural so that's why there's a bunch of them. But the good news for us is that we like open source and open projects and so not only do you guys not need to do the math but we actually didn't need to do the math either. We found a guy named Dan Royer had done a lot of this work for us in setting up a Delta robot that did most of what we wanted to do. He already had source code that would do the inverse kinematics which is the fancy roboticist term for turn what the robot motors do into the X, Y and Z motion. He also had 3D printed schematics and everything. He actually sells it as a kit. This one you're seeing here is built out of mostly his kit parts. The one that Paul built which is in the hotel room right now is actually completely built by us. We didn't want to be held hostage to them not selling it anymore. So we did build it from scratch from all other parts and it all works fine. So essentially what we've got is an Arduino, we've got the physical parts of the robot and we've got a computer and the computer is talking over serial to the Arduino and the Arduino knows how to move the robot around. So the original kit was missing a few things. It was just kind of an empty head. He didn't know what it was going to be used for. So we added a stylus to the tip and just adding a stylus makes it not work. You have to ground the stylus because the capacitive touch screen thinks that's what it touches is a changing capacitance. So we added that. We added a camera. So that helps us for configuration. We won't have time to show you guys that now but we can show it to you later. It also set up to recognize when the screen changes because that means that we successfully unlocked it. We are around moving at five presses per second but you'll notice there's a delay after each of the five. Most of the numbers I'm going to talk about assume that you can do one full pin so that's four or five presses in a second. There's some camera code that we can maybe modify to get rid of that delay in the middle. So all that stuff is done. We need to make some Python that makes it all work. So we have a serial port control in Python. Python makes that really easy. We used OpenCV to analyze the stuff on the camera and we have an easy interface for calibrating where all the buttons are. We originally tried to detect the buttons. It was too hard. Don't believe computer vision people when they tell you that they can just recognize anything anywhere. It's not true. And lastly it can detect you tell it where on the screen you want to say if this part changes then we definitely unlocked and then we watch for that to change and when it happens then we know that we were done. So we talked a minute ago about how you need to ground the stylus to make it actually detects a touch. So at some point when I was working on this I realized why don't we just hook up a bunch of wires to the screen on the buttons and then ground them selectively and then we don't need any moving parts. So you use a microcontroller connected to relays to trigger those in place that will then cause the touches to appear on the screen. And you don't need any moving parts. You don't need this complicated calibration. All you need to do is fire off the Python which fires the relays and it all works. Except it doesn't work. So the problem in my particular case the relays that I selected have enough capacitance by themselves that once you hook it up even if the relays open the screen sees it as a touch. I don't know anything about electronics. Does anyone here have an idea of what's wrong and how to fix it? Raise your hands. Yes there's all kinds of things we can try and I don't know what any of them are but if you let me know what they are we can try them. If we can get it fixed at DEF CON I will give someone a full R2B2 if we have C3BO working by the end of the time. So talking generally about brute forcing stuff. We don't want to just naively go through and start with 0, 0, 0, 0 and then go 0, 0, 0, 1. We got it. We cracked the pin. So what's the pin? We're looking for it. 7777? 1997? That was right before we pressed 7777. So what happens is we've got it actually multi-threaded so it's starting the next run before it's analyzed the picture to see if it's changed or not. So we can narrow it down but sometimes we're off by one. We actually saved the list of all the times that we think we got it so if we did get it wrong then you can go back and try the next few up. We almost got it. All right. So as I was kind of alluding to when I was talking to Sebastian we don't go in kind of stupid order from 0, 0, 0 to 9999. There was a guy named Nick Barry that did an analysis based on leaked password files to try to figure out which pins would be the most common. He had some really cool data visualizations but he wouldn't release his actual raw data. But what he did wasn't complicated so we did the same thing and in addition we pulled in more password files than he originally did to make sure we had more data. So we have the password list for that. It's included in the stuff we're going to submit to you guys so you can do this too. There's also a guy named Daniel Amitay. His was a little different. He wrote an app for the IOS that goes through and let someone add an extra lock screen to their phone and then he collected the pins that people were using for that and did aggregate statistics about those. So we asked him for his data and he graciously provided it. It turns out that it's a little different than the data that's just from password list because those are from people that are usually sitting at a computer. And so those guys don't do things as much where the position of the buttons matters. So 2580 is much more common in Dan's list than in the other list because it's just straight down the screen. Also corners, you know, anything else that makes a pattern or uses the letters. So another one that's popular is the one that spells out love. So it's interesting to look at those things. So the two datasets, the one that we synthesized and when I say we, I mean Paul, and it took him like a half an hour to write the code so I don't think we're really giving away any special secrets or anything. And we combined it with Daniel's list and the list that you'll have is the synthesis of the two. So this is what you need to know about pin frequency. So on the bottom we have the number of pins that you've guessed. On the top you have the percentage of phones that you've unlocked by the time you've guessed that many. So if you want to be more likely than not you have solved the problem and unlocked the phone, 670 pins is all you need out of 10,000. Assuming that the person that you are trying to crack is not some weird DEF CON person and actually follows the statistics. If you want an 80% chance that you've unlocked it, it's about 3700 which is still much less than the 8000 you would expect at 80%. Obviously R2B2 is also able to, because we're just a robot, we can push physical buttons as well as touch screen buttons. I don't have a demo for you because I couldn't find a good one. I almost brought an old tape calculator and had it push buttons but I couldn't fit it in my bag. We also think we might be able to do things that are completely mechanical. Like there's some padlocks that have buttons and things like that. If you've noticed all the doors around here seem to have codes on them. Sounds like everybody knows what it is already. So now that you know how to brute force something, how do we go the other direction and defeat brute forcing? So one thing you could do is have a delay after bad guesses. On Android, if all you've done is set a pin and you haven't set any other settings, all you've done is set a pin, then it makes you, every five bad guesses you do, you have to wait for 30 seconds. That 30 seconds is constant. So the next five you do, you have to wait another 30 seconds. That means that if you want to go through all 10,000, it's going to take you about 20 hours, which is not that bad for something that's important. And like we just talked about with the other ones, if you wanted to be more likely than not done, it's only going to take you 80 minutes. If you want 80% likely to be done, that's only seven hours. iOS is lock screen, handles things a little bit differently. So on iOS, you get your first five for free and after that it starts to scale up how long you have to wait between each guess. And it goes up crazy fast. If you take that 20 hours that we had for Android and you do the same thing here and you wait the required weights, you only have like a 20% success rate. So that's not 20% of the pins because that would be a lot more. That's 20% success rate. Another thing that's important to note here about Android is that there are many other settings you can set that will change this behavior. If you have a Google account set and you have two-factor authentication enabled on that, then after something like 20 guesses, you'll be prompted for your Google username and password instead of your pin. So that's good. If you're using your device for corporate email, hopefully your exchange, people have set up the wipe after 10 tries setting. So it's not like all hope is lost on Android. There's still a lot you can do. It's just a default. It's not as good as it could be. I'm mostly an app sec. So what I was more interested in is applications. We get a lot of clients that have a pin on their application separate from the lock screen. And it's that kind of situation where we most often find there's no brute force protection at all. And when we have an engagement and I tell them that there's no brute force protection, they say, well, did you break it? No, I didn't have time. And now we have the robot, so now we don't have that problem. We very briefly, because the robot was only stable, stably working as of a day or two ago, and even then we've still been tweaking code today. We only had time to test out a few apps from the app store. Things that are likely to have this are things like a financial apps habit, some antivirus apps habit, some things that are like store your secret pictures and notes habit. So out of 13 that we had time to try, four of them had something that was effective enough that we couldn't break it. The other nine had nothing that would really stop us. This is an interesting table. So this tells you if you can do one pin per second and there's no other brute force protections, how long it would take you to break something for various types of pins or passwords. And the other side shows you what it would be like on the Android style where it makes you wait 30 seconds every five bad guesses. So as you can see, it's not that hard if you do a four character password that includes all the printable ASCII characters, it's going to take me two and a half years, even if there's no brute force protection. And that's decent. If you can go up to seven, we're up to 20,000 centuries. My robot would be broken by then, I promise. So the last slide, this is my advice to developers of OSs or apps or whatever. You need to put some kind of brute force protection in place. This is my advice for users when you have to use an app that doesn't have any brute force protection in place, you need to pick a longer pin or one with better characters. This is not rocket science and this is something that the security community has known about forever, but at the same time, we still see apps with no protection. So I guess we have to talk about it some more. And maybe with this robot, we will finally get some traction on getting those things changed. I second NCC, thank you very much for giving us some money to build this robot. Dan Royer who did the original design that we modified, Daniel Amitay for giving us some data, and David Nichols who helped us with some app analysis. This is our contact information. That's my Twitter handle. Your CDs already have the kind of preliminary code that was working as of when they were due a couple months ago. It will run and it will move the robot. There's no camera code in there yet. The, I will tweet at this when we have the rest of it posted which will be sometime next week. And I think we can probably get it on the ISAC webpage. That's it. Thanks, guys. We have time for questions maybe? A couple? Yes, go. How many did we successfully break? How many guesses did it take? We're looking. We'll look. Next question. Paul is from Seattle. I am from close to Seattle. Yes. How much is the robot? Excellent question. If you have a 3D printer and you print the stuff yourself, it's less than 50 bucks for everything else. If you need to buy the 3D printed parts depending on what the pricing is from where you get it which seems to vary a lot, you're going to be probably just under 200 bucks, maybe 150. So not bad.