 Hello, and welcome to Rock the Cash Box. This talk is about hands-on ATM protocol analysis, and we'll be covering ATMs and, of course, the protocols that power them, at least one specific protocol. This talk has been made specifically for DEFCON 30 and Retail Hacking Village. I hope that for those of you who have not been at Hack or Summer Camp in some time, this will be a good refresher on ATMs. And if you're new to security and you want to know how ATMs work or you want to look at protocol analysis, this talk should and is tailored for you. I really wanted to focus on the basics and how protocols work. So with that, enough about the introduction, you really aren't here to just hear about the talk, you want to actually see it. So let's get started. So about me, I am Wasabi, sometimes Spicy, at least on Twitter, and I am a perpetual volunteer. That's how this whole event started, and that's how I get a lot of interesting ideas and work for some of the research I do. The events that I helped put on are the Collegiate Pen Testing Competition. The Global Collegiate Pen Testing Competition, my apologies, it's a very awesome competition, which is how we got to this in this particular year. They were tasked with pen testing a bank. And I also participate in the Collegiate Cyber Defense Competition, which is the severed defense aspect of that. These events are very interesting, and if you're a student, you should definitely look into getting involved. I am a researcher of embedded devices. I have researched voting machines, ATMs, of course, and many routers and other devices of an embedded nature. The great thing about embedded devices, there's always something new, and you may think, oh, this device is secure and it's fully updated. Nope, never is. So it's a very interesting topic, and I can go on and on about all the embedded devices that are out there today. This includes the Internet of Things, but we're really focusing on ATMs, and these ATMs specifically are quite old, but they're still in use. So it should be an interesting rediscovery for everyone. Now, I will be sitting in the audience probably that way, and if you happen to see me, please ask questions. I know that this is a little weird. I was not either expecting to be doing a in-person talk via recording, but here we are, and I'm grateful for this opportunity because, for one, everyone's going to be wearing masks, and two, this gives me an opportunity to make sure that all the content and demo and videos are all working as expected because if anyone's ever done a talk before, you know things go sideways. Anyway, finally, I am a cloud engineer by day, so none of the stuff we're talking about really is my day job, but if you are interested in these topics, I'm happy to answer questions or find people who might know or do know the answers to these questions. Now, my partner with this was formerly known as JRWR. He's now going as Balsa, at least on Twitter. He is the creator and designer of Hatchan. He is working with the Defcon scavenger hunt for some really cool stuff this year, and so you should go check him out. And also, he does some really interesting work on some CTFs and things like that. Overall, he is a really good guy to work with, and if you have any questions about so many topics, please go reach out to him. He's awesome. Unfortunately, I don't think he's going to be here today because, of course, he's running the scavenger hunt, but wanted to give credit where credit's due, and that was the team that helped make this happen. So anyway, you're here not to hear about us, of course. You're here about rocking the cash box. And fun fact, if you ever see an ATM do what's in the picture, it's fake. It's, in fact, so fake that it's been modified. It's tampered with. It's not real. In fact, the ATMs that we're dealing with, that is one of them. They have a guard to prevent money from flying out because, as one should with designing an ATM, you probably don't want the money flying out into the air. And of course, what is a cash box? Well, inside of an ATM, you have to get money. Now, unlike a vending machine, you don't want to have the vendors who refill the machines handling the money. They could take some, do all sorts of stuff. So they are handed cash boxes with specific keys, and the machine can pull money out of that cash box. So our goal is to get the money out of the cash box, and how are we going to do that? Well, we're not modifying the ATMs. We are not modifying the firmware. We are not doing anything with the ATMs, in fact. The ATMs are stock. We have not customized them, except for maybe a few repairs because the ones that we got were in pretty bad condition. We think this talk at very least is interesting and unique because not many people have looked at the protocol, oh, my headset's falling off, looked at the protocol that powers a lot of these ATMs. These ATMs are still in use, and so we are specifically talking about that protocol. That powers them. And we are bringing ATM protocols, at least one of them, to the masses at DEF CON 30 retail village. So I'm excited that everyone here is interested in that. And again, feel free to ask me any questions. So here's a photo. This was actually a couple of weeks ago. That is, in fact, the same ATM that we will be talking about today. And it, in fact, was out of order. I almost was tempted to offer them a fix, but I thought better of it. So the background of this event and why we got so many ATMs and why we had to do this was ironically enough, the event was the Collegiate Penteson Competition, and it was a prehistoric bank. And of course, we got prehistoric ATMs. These are circa 2000 to 2004, and then there was an EMV update in around 2010. I guess that's still a lot more modern than some may expect, but they're fairly old by ATM standards. And so the simulated bank had a lot of custom applications. We had custom tools and everything built to simulate custom software and what a real-world pentest would be like. And the students are required to write a report on their findings. In previous years, some of the event, well, at least the past three or four years, teams have found ODES on the software that we use. It's not that the software is custom in those particular cases. It's actually off the shelf and we did not know there were vulnerabilities, but because of the pentests that the students are performing, they find vulnerabilities. It's actually very exciting. We look forward to those findings every year. And so far, the teams have not disappointed us. It's a really cool competition. And if you're like, oh my gosh, I don't think I can find zero days, ODES, sorry. However you want to say it. Don't worry, the competition is meant, it goes through a regional qualifying and several rounds. We want it to be fun. So not every team finds vulnerabilities like that, but the key thing is it's a very interesting competition. We try to make it as realistic as possible. But you're probably wondering, how did you get ATMs? Well, it turns out you can buy anything on eBay and sometimes in great numbers. Turns out you can get an entire truckload of ATMs for maybe less than $500. And maybe you have to get that from one state to another and travel over 1,000 miles, just things. And the good news is the mission impossible for ATMs was a success, the truck almost flipped once and it was a journey. But purchasing ATMs, it's a very strange world. People are no questions asked and they expect you to just deliver an ATM or get an ATM and buy it and take it away. So it's interesting. And all of these were from various locations. In fact, a lot of the ATMs as we were analyzing the configurations were from Waffle Houses. So some of them actually were sticky. One at least had some dead critters in it. They were pretty disgusting. But as it turns out again, you can pretty much buy anything, this is the current listing. The bottom one is a single one for $300. We did much better than that, but you can see all the different variants of the ATM machines and parts. So here are all the ATM machines running in unison. I don't think that the audio will come through and in fact the video footage is pretty broken. But that was all the ATMs and doing their boot up. So unfortunately the videos probably won't work today. So anyway, the problem with the ATMs was they were in bad shape, they were falling apart and we needed to find a way to communicate them. So first we found the working ones and then we had to figure out what to do. So it turned out there were a few things, not just one thing. And so we tried to find the user manual. Of course the user manual is meant for users and not people trying to make the ATMs work. Most of the time you go through a trusted vendor to buy your ATM and get a actual service for the payment processing. And our goal was to make them work. That was the most simple goal of them. We weren't trying to reverse engineer a protocol at the time, we just wanted to see what can we do? Can we make them dispense money? Can we do anything? Of course it says out of order unless you do the correct sequence for the protocol. And so we were running into some issues. And our final goal was to make it as realistic as possible. We didn't have any defined goals. We didn't have anything other than make them work. So our one item was where we started. Of course the ATM itself is a Tranax mini-bank 1500. Hayu Song is the brand who took that over as far as I know or one of them bought the other. So you see various names of those interchangeably. And some models actually support up to Windows CE 6.0 with EMV support. Now, Windows CE 6.0 of life took place in February 2022. So I guess it was fairly modern until recently, but it is what it is. And the main problem though was that was released in about 2014 and they don't receive any updates since. And with that upgrade you'd be switching between the current protocol we use and Ethernet if you so desired. However, in our particular case the ATM did not have Ethernet. It supported 56 Bod Modem and that was it. And there was a safe fun fact. If you can get that door open on the bottom where the money dispenser comes out most of these ATMs are actually programmed for code 1234 or 000. There were a couple where we actually had to get the locks, like they were spin locks. And so we had to actually listen and get in that way. But for the most part the ATMs were with a default code even though these were directly from the vendor. They said they didn't know the pins. So we ended up Googling and that was the answer. Google is your friend. So specs, it's a pretty old system. It's powered by a 16 bit microcontroller. Main communication mechanism is the dial up system. The pin pad contains the crypto keys. If you remove the pin pad it resets and then nothing works anymore, you have to reset it. Printer controller also uses the same processor and is an independent board. This allows you to update the main board while keeping the dispenser controller and the printer controller the same. All of it's communicating via serial. People have tried to attack the serial protocol but that was not as interesting for us because that means you have to have physical access to the ATM and as we all know, once you have physical access all bets are off. So with enough determination you could break in. Here's a picture of the classic main board from the ATM. You can see the main logic chip right there. There's a real time clock that actually did not work. I believe because these were the ones with the integrated battery and those go flat after a while. But either way, didn't quite work. So you can see here where the main board is, this is a different variant. You can see all the connections to the main, or the accessories to the main board. And then there's this one little thing. If you take a look with the question mark that wasn't a soldered on accessory board. We're not quite sure what it did. If you flip the dip switches it would not boot. We couldn't find any identifiers. It is a microcontroller of course on there, but what it was actually trying to do and how it was connected, we weren't able to fully trace. You can see the FPGA and the memory on board. Overall fairly simple setup, but this is what powers the ATM. If you want to get the upgrade, the upgrade you can see the LAN and modal options. And it's now in a metal enclosure and then it has a new display board and the EMV compatible reader. Of course we didn't have this and we weren't really trying to. We were just trying to get ATMs to work. So we figured EMV would add to the complications. And of course it did, but it does, but we didn't deal with that. So how does an ATM work? And if you're new to ATMs and maybe I'm, you know, or not as familiar, I may be going over these things in a basic sense, but again, this is for people who are not familiar with anything. So we're gonna go to a little bit background quickly, but ATMs are usually need to communicate to a payment processor. If you go over a network that can be online and whatnot, if you're going over the phone, there's two options. You either have to have a local payment processor that converts the dial up communication to ethernet and then off to the actual payment server with more security and whatnot. Or you have to connect to a dial in payment processor. Way back in the day, this was known as VisaNet and we'll be following that again in a little bit on the talk, but we didn't have either. We didn't know where we could obtain a local payment processor and we had no operating manuals or guides or figuring out how we could connect. The only options we had was to actually pay a service to give us access and as an academic competition, we don't have a lot of funds. So that was off the table. Our first thing to look at, can we emulate the payment processor? And of course we did, but we weren't quite sure how. Of course, near the end of the competition or right before the competition, one of the volunteers was able to obtain an actual payment processor. This one is the external for localized payment. In is the modem and out is ethernet and it connects to the internet. You can configure it using the ethernet port and this allows you to communicate to either one or multiple phone dial in ATMs. So in the competition setting, we had a challenge. We had, I believe, eight or nine ATMs in use. We needed a way for them all to communicate and we only had so many Raspberry Pis and phone modems, USB modems. So how do you do that? Well, we ended up buying some PBXs to allow banks of ATMs to communicate to the PBX which would then connect to two lines in to the Raspberry Pi. This allowed us to have two simultaneous connections and then the additional ATMs would be queuing until they were able to dial to the payment processor. Each, in our case, which was the Raspberry Pi and then each Raspberry Pi was connected to a central processor which connected to our simulated bank. And then, of course, the challenge was before all this was set up, how do we communicate? So in my case, I was one of the developers so I connected to DevSystem which tunneled through the internet to a jump box at, I almost said JRWR, but Valsa's house. And then it could tunnel to the Raspberry Pi which then allowed us to communicate to the ATM. Now, the many layers of connection posed a problem because if you killed the connection to the Raspberry Pi or the Raspberry Pi crashed, you might still be able to get to the jump box but the Pi would be dead and you'd have to reboot it. And then the other fun was the modems would lock up and you'd have to physically reset them. So those were quite a few challenges that we had to deal with and then, of course, a few times the jump box itself would just die so the Pi was up but we couldn't reach it. So it's a bit of a challenge and then, of course, because all the ATMs were on the East Coast and I was on the West Coast, we had to work through the time zone challenges where things were very challenging sometimes when I would be working at 9 p.m. or 8 p.m. and it was almost midnight for Valsa. So that was a challenge but we worked through it and we found out a couple of things. Dialing, dial up is a bit of a lost art. A few years ago, there was a CTF at DEF CON that used dial up modems for people to connect in. I thought that was very cool but it's a bit of a dying in lost art because people don't really use this. We had to get used but new and I say that with quotes, of course, because they were pre-used on PBXs and we had to find USB modems compatible actually with the Raspberry Pi and Linux. And then, of course, we had to find how to dial into the ATMs or have the ATMs dial. And then, of course, how many retries and how to get them to communicate was a problem. And of course, the PBXs we got were off eBay and they were the wrong frequency, 50 versus 60 Hertz to communicate. So we had a lot of things going against us to figure out how to get this all working. And for those of you who are familiar with dial up, it was a learning experience and I'm glad I learned it again. It's been a few years but it's something that we're just not familiar with anymore as a team because most of the time you're dealing with Ethernet or Wi-Fi. So of course, this is the simplified diagram of the payment processor. The payment processor can operate off of the Raspberry Pi or a micro router running OpenWert, which connects to the USB modem and then to a PBX. You probably don't need the PBX to directly communicate but it's a good idea. And then, of course, you can control in the final version, the one that I've released more recently, you can control the way the ATM operates from a web interface if you connect over Wi-Fi. This can force the ATM to accept or reject cards, change transaction fees, and of course, manipulate the payments in transit. So for example, if a user thinks they're getting $20, you can request $100 out of their bank account. And then the user gets back a validation, of course, not quite the correct validation that they expected. So that's the process. The only thing that's interesting for this is it actually checks to make sure that it's a valid card type that it knows. The ATM internally does. So we were trying to find ATM valid cards. The only thing that we were able to obtain that wasn't an old credit card because we didn't wanna hand them out for the competition was gift cards, visa prepaid gift cards. So those actually were accepted and we were able to use them and read the card data. So of course, we worked on weekends and weekdays to get this working. Of course, I would start on the weekends at least at six a.m. Pacific time, which was about nine a.m. Eastern. We would spend the whole day over discord or voice call and the end process was trying to just get them to communicate. We had two ATMs at once, but only one Raspberry Pi. So what this, and because we were working in parallel, trying to understand how these worked, we rediscovered time sharing because we would have to split the workload and wait till someone was done dialing in to get everything. And of course, we rediscovered at commands, which are very fun. The ATM internally uses at commands, as well as at commands are required to ring and hang up the modems. We needed some way to configure the ATMs, of course. And the challenge was we weren't familiar with these ATMs. They have a guide, but it's a general maintenance guide. And the good news is the US Robotics still sort of exists and they have actually some great documentation as long as you're able to use an old browser, which was not so good. So here's some of the key at commands. Plus plus plus, which is the command mode. And then A is answer. And then there's A slash, which is of course, the repeat. There's dial. So when you do the ATS zero equals two, it would auto answer and you needed the proper new lines, otherwise it wouldn't communicate right. So that was a lot of fun. So of course, once we got this working, the ATM would dial, it would send a message and that's it. How do we know what it's sending? And in this particular case, you can see the data when we were trying to decode it. And we were seeing a pattern. We were seeing data, but we weren't quite sure what it was. So we really didn't know and we tried sending the same string back. Maybe it was a handshake. But really we were only getting a reply from the modem and it's even funnier in a second because we were trying to make this work. We started with PySerial and that wasn't good. We tried Screen because we thought maybe it's just in a different encoding. Then we tried Minicom. And then we actually switched to intercept PTY, which is an old program. You compile it and it outputs a socket that allows you to run two things to the specific serial line. And that allowed us to run our Python code and Minicom to monitor the messages at the same time. Of course, with Balsa, everything is in PHP. He once described it to me that he is the Jack Sparrow of PHP programming. And I can't disagree. You don't know how he ends up with the stuff he does, but it works and it exists. So we tried PHP but it wasn't quite working. It was impressive how far we got with PHP, considering it's not really meant for serial work. But overall, the serial was just unreliable. We kept seeing messages and we kept seeing them stack. So we knew something was going on, but we weren't quite sure we saw the patterns. And so we switched back to Python using the OS sockets for serial. We thought maybe it's encoded. So we started looking for the patterns. And if you're ever doing protocol analysis, it's a really good idea to start breaking down the messages. If you look at some of these screenshots, you'll see new lines. But in this case, I was looking for patterns. We found 94, we found 0D0A, and then we found other strings of messages that were grouped together and then it was repeating. There were some F7s, lucky sevens maybe, I don't know. But you can see I started highlighting things to try to find a pattern and where things started over. You can see because of the sevens, we were able to roughly get a reset of where the communication started over. So it wasn't actually just continuing the same message, it was resetting. You can probably find more patterns than this, but that is not necessarily needed as long as you can make the structure. We did have a major oops moment though, because when you just decode the text to ASCII, you get ring, ring, ring, connect, no carrier. Ring, ring, ring, connect, no carrier. Where was this coming from? Well, I will give you a hint, it is the modems. I guess that's not much of a hint, it's more of just the answer, but the unknown part, this FFF and sevens was something interesting. We couldn't quite figure out what this was, but we figured it was from the ATM. So when you're looking for patterns, you're trying to find, especially with unknown protocols, protocols generally follow a structure. Even if they're encrypted, there's usually probably some kind of like preamble or repeating pattern. I broke off the different hex to show you how it looks. And so we were looking for like line level to see if maybe there was a pattern, like you have to go so many highs before a low, looking for a start of packet by the pattern. This is all logic signaling. So if it's high or it's low, it allows you to really start seeing if maybe there's like a sequence, you can see what the 077, this of course is a character, but you can see there's a distinct pattern. And when you divide these by time slots, that's how computers are able to process these and process the signal and respond. So we were looking for something that a machine might recognize. We didn't quite see anything, but we kept searching through vendor sites. The goodness is the vendors talk about how this supports amazing encryption, including DES compliant or triple DES encryption and visa certified pin encryption. So don't worry, it's safe. But we were trying to find guides and documents and we were really struggling. And then we found a vendor guide and this vendor guide was not the typical vendor guide. It was very detailed and it was listed as a draft. So that was exciting. From the documentation, it spoke about how the modem connects. It talks about the bit configuration, the parity and the way the message must start. So these are all ASCII control characters, STX, ETX, and E&Q. And specifically, it also spoke about how to configure and reset the ATM. And we are using, I believe, standard three, these EPS link and ST3 link are ones that we didn't use. ST standard three is what we used. And so we, from researching and being able to, you know, with the breakthrough of the protocol or the vendor guide, we were able to start figuring out the protocol. So the standard flow request was terminal call, it'll ring, it sends an inquiry. Then we get a request, response, AC, end of transmission, end of transmission, everyone's happy, disconnect. But how does that work? Well, we knew that from the vendor guide that it's supposed to do an E&Q to start. So we were sending E&Q and it just ignored us. But when you start looking online, and it's actually really funny, this was an old Frac article from 1994. And on the other side of this article was an advertisement for DEF CON 2. So 28 years later, the Frac article is relevant again. It was really cool to see that, though. But based on VisaNet, it turns out that the way you trigger it is you send E&Q, E&Q, E&Q, which would trigger the ATM to respond. Good little tidbit. This was not documented anywhere else. And so once we found this, we were able to get a message. So this is the message we were seeing. And we were so excited, we got a message back. It's funny actually, because I'm looking at this message and I can see where the different protocol structure is for the different payment parts and things like that that it's trying to do for the setup. But this was the message we got back. And we didn't see any in QBAC, we didn't see any TX, we didn't see a NAC. So what happened? It doesn't seem to match this at all. And well, we were a little concerned. We started looking at the manual again and it says that it can operate either in a batch mode where it queues up all the transactions and then sends them all at once. So if someone wants to do a withdrawal deposit and things like that, it'll queue them up until they're ready to do a single transmission and send it over. Or it can do single mode, which every transaction is a dial in and request. We tried both, concerned that maybe we had accidentally got it into batch mode, but the batch mode was unlikely because it requires a keep alive connection with the payment process. So it dials in and it keeps sending messages back and forth. We didn't want to handle that. So we went with the simpler single option. So we were trying to figure out what's going on. We started doing parity bits and it's a challenge. We were not familiar with the raw parity bits because we don't really have to deal with it much. So we were able to identify some characters and find valid stuff, but we weren't sure what was going on. We tried shifting over and you can see when you shift a message over, some of the stuff rolls off and it's, you can restructure the message. But that didn't help. So it wasn't just a pure shift. But the question was why would sending a valid E and Q return a response, but not the invalid one that we were getting back? Well, it turns out with classic protocols, classic ASCII, the only six of the bits are used. The seventh bit is the parity bit. The parity bit is allowing it so that you can make sure that a message comes through correctly. And so in our case, we were able to drip the parity bit and get the correct ASCII code. Usually the seventh bit, the eighth bit actually, sorry, is not used nowadays. It's just static, but it can be used. And so that was how we were getting messed up because it was error detection. Even our odd, it would either get turned on or off. So we were seeing some valid characters and some not. So now we were getting an actual message back where we could actually see the ASCII control characters. And of course, that was a challenge because we weren't sure what was going on. We got these messages back, but we were like, huh, there's some blank parts and things like that. We were trying to empty out certain fields to see what we were doing. I have actually transcoded this into things that it is. This is the terminal ID. This is a field separator, field separator, the transaction code. And so we were able to start building up like what was what by editing the ATM configuration to send out specific messages. Of course, things still didn't work. There was a LRC at the end for parity. It was trying to make sure that the messages were good. It's essentially like a CRC or a validation bit. And I got a bad implementation that I'd used to implement. And it was overly complex and didn't work. So we were sending the wrong LRC. What we ended up doing was going and finding another reference guide to make sure we were correct. And there's a couple of ways you can do this. If the field is small, you can make a table. Lookup table to make sure that you have all the values based on a specific calculation or you can do what in this case, and that would be like CRC. In this case, it's even simpler. It's just bit math. And so we were able to get everything out with that. And once we got this, we would, with the invalid one, we'd get a knack. And once we sent the valid one with the message, we got a knack. So that was a nice progress. So how does it work? Now we're talking to the ATM and that's really exciting. Well, the ATM does a host download table request. This request gives the ATM everything it needs, including encryption keys, charge amount, and a few other values. It supports up to triple des with left and right key combos. So you could do multiple hosts. So not everyone knows the whole key. It's a 64-bit key. However, what we found is you can also just send it to all zeros, which is great. And so when the ATM loads this up, everything is just zeros and it's like, okay, cool. And that makes it really easy to decrypt. There is a actual standard, the ANSI standard for pin management security, x.9.8. And it actually is where this comes from that the pin codes will be 64 bits in length, each nibble being stored as an ASCII value, zero through nine, A through F, as a Hex representing the Hex characters left to right. So that was interesting. That was actually a well-documented piece. You can actually see it here. This is the protocol handler that we wrote. And you can see the messages and sending messages back. It was actually a very basic message handling. You can see below the field separate terminal ID, code, encryption, field separator. And so this is all the messages, the data and breaking it off and where we would have like dangling bits and bytes. So we were dealing with the extra characters and trying to find the replies and we would always get either a success or a failure and that allowed us to keep moving forward because it was very simple in response. Did it work? Nope, okay, let's keep trying. So that was helpful. You can see at the end, we got the ASCII character, the control character. So, but it was still sending a failure. So we also needed to send a second message. After the host download, we needed to send the host totals, which gives the ATM the information about the date, the time, the fees and a few other fields. But because we were having to handle these messages afterward, we realized that we have to build a state machine. So state machines, for those of you who are not familiar are very fundamental of computer science and building. It allows you to build essentially code that works through a flow and allows us to take steps to go either go back to the beginning or reset or follow specific conditions. And it allows us to scale with new protocols and messages and see what's going on. So from the start, we receive either nothing or we get a clear parody bit and then complete the handshake, start the timer. If everything does not succeed within 30 seconds, reset back to here and wait for a message. If it's success or failure, failure, you stop and the message send a failure. With success, we have a few things that we have to check for for the messages and then the message type, we can send it off, see what it is and then send it to our payment processor. The original code looks something like this where we are hand constructing the message and looking for the parody to make sure everything worked and I do love the comment at the beginning. Encryption keys should be changed from static at some point, probably a good idea. But from that big block of text to something very simple where it just is process message, if everything works, send it to the handler and get the handler's response. Very much cleaner and it allows us to do things like this where we can see unknown messages, unknown parts, process the messages and you can actually see here in this message the components that actually make up the terminal ID, transaction code, the amount, the pin block and then all the other data that is associated and so then we can send it back. So once you get an ATM working, you need to get everything working because it's out of service. So once we were able to get the ATMs in service, we started working on a protocol to allow the ATMs to communicate to us in a meaningful manner. So this one is the first successful message that we had and you will see in a second that it actually, I don't know if you can hear it dialing, but it makes the actual dial up noises and then thanks for a second and then now it's gonna spit out the money. And so that was our first successful message through. The problem was, again, we were on a budget, this is not real money, this is play money and the ATMs are designed for a specific fabric type and weight. So it was shredding all our fake money and we found out that Jamaican currency is the perfect format for emulating real money because it's very cheap for us at least and it doesn't get shredded. So the end result was we support and we built out support, I should say, for over 20 different transaction types. We actually wrote 10 types and then there's six, and then there's success messages, failure messages error, where we had special response handlers for those. We only read one track on a two track card. Usually there's two tracks, one with the card number and then some name information. Only track one is red, that's not a feature of us. We can't read the second track really. It only is coming through with the ATM. So we only can read what it provides. The hard part was actual padding. It's a zero padded number. So you have three sets of pairs of zeros, so six in total and you have to move it over to either get cents, dollars or a larger amount. When you don't pad it correctly, this was all static when this was done. You can either get negative numbers or cents. So this was a ledger balance of a negative amount because you input all these values. Each one of these is a field back from the payment processor. It's not actually necessarily counted in the ATM. Well, the fees are counted in the ATM, but everything else like ledger balance, dispense, requested, fee, those are all responded back as the ATM. So here's a successful run. This was actually at the competition. So I'm gonna mute it because nobody can hear that. So she successfully did the enter to send the message and then you could see it where it took a second and the screen updated and the money came out. So at the end of this, what we wanna do is switch gears a little bit and ask ourselves why are 16 to 20 year old ATMs still in use? Why is the protocol still the same way? I know we're going to EMV on a lot of these and that's a much better protocol, but as you were seeing at the beginning, it's still Windows CE6, which is end of life. Those ATMs are still going to be in use for many years. And it is an expensive upgrade at that. So it's something to think about that these ATMs are still out there and that people are putting their banking details into these systems. There is some security, but Triple Des is not exactly known at DEF CON for being particularly good, let alone anywhere else. So we really need to think about that. And when designing protocols, yeah, these were designed in the late 90s, early 2000s, but we need to be making security first focus protocols for especially making systems and we don't. There's modern stuff, let's use it, maybe at least HTTP instead of unencrypted dial up. Not much better, but there's HTTPS, there's WebSocket, which should be used and can be used. And, but most of all, make the modules upgradeable and cheap because at the end of the day, if you give someone an easy way to upgrade their components, they will. And they will use the security that is provided to them. Most people are not security experts, so that would be a good point of starting. Anyway, I'm happy to answer questions. I will be wandering around the village, maybe waving at this point. If not, you can find both of us on Twitter, you can ask there, and you can download the ATM processor firmware yourself. It uses open word build image builder to build a custom image. All the code is based in Python, so you can get that working, has the webinar face, and you can go from there if you happen to have the specific ATM or series of ATMs. So with that, if there's any questions, feel free to ask me, and then if not, contact us. Alrighty, thank you.