Electromechanical PIN Cracking with Robotic Reconfigurable Button Basher (and C3BO)
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Engler, Justin
Vines, Paul
Password and PIN systems are often encountered on mobile devices. A software approach to cracking these systems is often the simplest, but in some cases there may be no better option than to start pushing buttons. This talk will cover automated PIN cracking techniques using two new tools and discuss the practicality of these attacks against various PIN-secured systems. Robotic Reconfigurable Button Basher (R2B2) is a ~$200 robot designed to manually brute force PINs or other passwords via manual entry. R2B2 can operate on touch screens or physical buttons. R2B2 can also handle more esoteric lockscreen types such as pattern tracing. Capacitive Cartesian Coordinate Bruteforceing Overlay (C3BO) is a combination of electronics designed to electrically simulate touches on a capacitive touch screen device. C3BO has no moving parts and can work faster than R2B2 in some circumstances. Both tools are built with open source software. Parts lists, detailed build instructions, and STL files for 3d printed parts will be available for download. A lucky volunteer will get to have their PIN cracked live on stage!. Justin Engler is a Senior Security Engineer for iSEC Partners. Justin specializes in mobile and application security. Justin has previously spoken at DEF CON and BlackHat. Justin is not a roboticist, but will play one on DEF CON TV. Paul Vines is a student at University of Washington and an iSEC Security Engineering Intern.
 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 that it removes the protection. This would be your best plan. It's usually quicker. It's usually a 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 approach. You can do a software approach. This would be a hardware attack. Our example here is keyboard emulation. Darren Kitchen at hat five has a neat video where he plugs in 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 a very important thing. 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 have any way to guarantee the intern gets it right. My boss Andrew loves his coffee and if I take the intern to push buttons all the time he won't be able to get any coffee. 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 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 has 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 they 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 his own by NCC group which is a company in the UK. Maths 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. 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 new system that 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 opened source most of it. And 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. The Arduino knows how to move the robot around. And we've got 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 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 watched 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 C3B0 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. 1997. 1997. 1997. 1997. 1997. 1997. 1997. 1997. 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. So 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 9, 9, 9, 9. There was a guy named Nick Berry that did an analysis based on leaked password files to try to figure out which pins would be the most common. And he had some really cool like 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 Amity. His was a little different. He wrote an app for the iOS that goes through and like 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 data sets, 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 DEFCON 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 R2-B2 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 to 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 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? 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 waits, 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? 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, stable working as of a day or two ago, and even then we still have 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.
 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 that it removes the protection. This would be your best plan. It's usually quicker.  It's usually a 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 approach. You can do a software  approach. This would be a hardware attack. Our example here is keyboard emulation. Darren  Kitchen at hat five has a neat video where he plugs in 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  a very important thing. 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 have any way to guarantee the intern gets it right. My boss  Andrew loves his coffee and if I take the intern to push buttons all the time he won't be able to  get any coffee. 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 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 has 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 they 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  his own by NCC group which is a company in the UK. Maths 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. 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 new system that 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 opened source most of it. And 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. The Arduino knows how to move the robot around. And we've got  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 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 watched 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 C3B0 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. 1997. 1997. 1997. 1997. 1997. 1997. 1997. 1997. 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. So 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 9, 9, 9, 9.  There was a guy named Nick Berry that did an analysis based on leaked password files to try to  figure out which pins would be the most common. And he had some really cool like 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 Amity. His was a little different.  He wrote an app for the iOS that goes through and like 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 data sets, 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 DEFCON 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 R2-B2 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 to  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 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? 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 waits, 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? 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,  stable working as of a day or two ago, and even then we still have 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.
DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_0_611.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_612_983.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_984_1127.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_1128_2951.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_2952_3215.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_3216_3863.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_3864_4931.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_4932_5771.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_5772_6215.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_6216_6347.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_6348_7895.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_7896_9227.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_9228_10235.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_10236_11279.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_11280_12191.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_12192_16607.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_16608_17615.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_17616_18575.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_18576_21383.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_21384_23015.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_23016_24071.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_24072_24395.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_24396_25031.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_25032_25535.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_25536_26759.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_26760_27575.png DEF_CON_21_-_Justin_Engler_and_Paul_Vines_-_Electromechanical_PIN_Cracking_3E8lQO9rmn8_27576_27762.png