 How many of you have ever used a vending machine? Who has ever wanted to hack them? All right. So this talk is for you. So just to introduce myself, I'm a security engineer. I'm from Switzerland. So no, I don't speak Swedish. I don't know, but many Americans think we speak Swedish in Switzerland, but no. I speak French, so excuse my English. I also do a lot of gifs. I love old video games. I brew and I love beer. And as you said, I'm a noob speaker, so if you have any comments, it would be great to appreciate it. So how did I get there? First, some years ago, I created a main cab, so it's basically an arcade machine with a laptop inside, and I play video games using emulators with this. And to be more realistic or to take money from my friends that came to play at home, I started, I searched and I bought a con acceptor on an auction site, and this is the tale of what I did with this. So first of all, any kind of machines that accept coins or bills are used every day, especially I think in casinos or in Vegas, like ATMs, vending machines, slot machines, et cetera. And there are multiple devices that are used to process money and give money back. For instance, coin and bill acceptors that are obviously used to count coins and bills can also detect if you insert a false coin or a coin from another country, et cetera, et cetera. And it uses methods to recognize the money for the weight, for the size, even visually. There are many ways to recognize that, and it's used to send if the coin has been accepted to the main board, and the main board needs to process the events that a coin has been inserted, and it's the machine that process that you have entered, for instance, one dollar or et cetera. Other devices are coin hopers that is used to give money back, so when you need to get the change, so it's pretty much like a big tray that operates using some commands and gives you the money coin by coin back. So if you need to receive back like $1 and this tray contains quarrels, the main board will send a command to release four coins so you can get your change back. All of this stuff communicate with several protocols. They are parallel, serial, another protocol is MDB and the last one is CCtalk. All these protocols are very vendor specific, so one vendor can do normally only CCtalk or only serial devices, so you need to check whether you get the right protocol you want to use. So since I didn't know about this, I just received the Mycon acceptor and it was a CCtalk and this is what we will be talking about. So CCtalk is a name for coin control stock, it's a semi proprietary protocol maintained by a company in England called Money Controls. Semi proprietary because the specs are available on cctalk.org but some parts of the specs are only available after signing an NDA. So you just have parts of the information but not everything so you have to find something and check this. How does it work? It's simply a request and response protocol, so just send a request, the device sends you a response and that's it. It uses an UR data transmission so it's pretty much like a serial communication at 0.6K, 8 and 1 on TTL signals and each device is on a bus and it has its own address, for instance one is the controller, two is the coin acceptor, four T is a coin hopper, etc. So on the same bus you have all the devices that can communicate between each other. A frame, a CCtalk frame looks just like this, so you have one byte for the destination address, one byte for the data length, one byte for the source, one byte for the header, I'll talk about this later. Several bytes of data, it depends on what command you will send to the device and a checksum. The header is the command that you will send to a device and if the header is equal to zero it means it's a response so you don't actually have a response to what. So you need to know what you asked to get the correct answer. The checksum is a simple checksum, it's just a complement to 255 of the whole packet. So all of these headers are commands, as I said and from the documentation you can find, you have the list of all the headers and you have, for instance, all the headers and the corresponding commands and if you get in the documentation you have all the data you need to send when sending a request and all the data that comes back so you can actually see or understand what's going on in the bus. For instance, you have a sample command that is sent, you can see that it's a sample poll so it's kind of like a ping for a device on the bus that is sent from the address one so it's normally the main board. To a device at address number two, normally a coin acceptor and if you send this, you will probably see a packet like this on the same bus which is a response zero to what we don't know from device at address two to device at address one. So just again, just by looking at those packets at the response you cannot know exactly a response to what it is. You have to sniff the bus all with the request to actually see the response and know exactly what it is. The second packet here is header number F6 in X which is request manufacturer ID and in the response you have NRI, it's the manufacturer of the device I bought. So I've been able to ping this device to know some information about this. Now I want to actually know if there was a coin entered, if it was correct, if it was one Swiss franc, two Swiss francs, etc. So in the documentation you have header number 229 that you just send to a coin acceptor and you receive back 11 bytes. The first byte is the counter and you have five groups of two bytes as a result. The counter is actually every time the device has a new event like you inserted the coin, the coin was accepted, was refused, etc. This counter is incremented. So for the main board you have to actually know which was the state of the counter and if there's an increment you know that there was a new information and you have to pass it. The results are sent in two bytes as I said. Normally the first result contains what is called the validation channel. On coin acceptors you have what is called validation channels. It's normally 16 ways or kind of coins it can recognize. So you can make the device learn 16 different coins. And each one of these is assigned an ID and it's that ID that is sent in the response. So there's a nice trick there because since you only have the ID, the coin acceptor only knows an ID. It doesn't know which kind of piece of coin or its value. It only knows an ID. And the main board needs to correlate the ID with the actual value of the coin that has been inserted. We'll check that after. The second byte contains the error code so it's if it's a bad coin if there was an error recognizing the coin or if the coin was accepted. The problem is that all these codes are vendor specific. So if you buy different kind of coin acceptors, they won't be the same error codes or error IDs, et cetera. And even sometimes the two bytes are swapped. So you really need to have the documentation or you will have lots of trouble when doing this. So for my initial project, I implemented the CCTAC protocol on a small TINSI device and it simply pulls a coin acceptor sometimes. And as soon as there is a new coin inserted, it will send a keystrokes to maim the emulator to actually insert the credits in the game. So here you have the board. There's a bus pirate there behind. That's because it was only for debug. You have the TINSI right here. The coin acceptor there. And if I put some money, the game will see that there are new credits. If I put two Swiss francs, there are two new credits, just there, et cetera. So that way I had the first part of my first project was nearly done so I was able to put it in my main cab. It was working. But I was telling me, can we do maybe more because that's a simple project. It only uses the coin acceptor I bought, et cetera. And there are many other machines that use those kind of protocols, et cetera. But the problem is that it's difficult to track those responses. You cannot see them because the header is always equal to zero and you don't know which answer is to which request. And I didn't find any open source sniffer for CC talk. So I created two tools which are called CC sniff and CC parse that I use to sniff data on a CC talk bus. And the other one is used to actually parse the data you sniffed in a way that you can pretty easily understand and learn exactly what happens on the bus. If you want to have a look, can everyone see correctly? Yeah? All right. Sorry? Can't do any more. It's a little bit bigger. Maybe you'll see, bearer. Ah, sorry. Well, so you have on the upper side, the packets, all of them are the packets list that you can select. And when you select a packet, you can see on the bottom the header the corresponding function directly so you don't need to check on the table, et cetera. You have the road up of the packet. And if you take some other packets like the one I showed you before, the request manufacturer ID, when you check the response, you have an automatic payload decoding. And it's the same for nearly all of the CC talk packets and responses. Again, if you check the read buffered credits on our codes, so the one used. Hi, everybody. The audience member, volunteer. Come on. You, sir. This meant you get to watch us. We've been doing this all day. Thank you. All right. Is it your first DEF CON? Anyway. Cheers. I don't know. Okay. Where are you? All right. So, yeah. Okay. So as I said, this is read buffered credits. So I pulled the con acceptor to actually get me the data, the status. And I have all the details. The event counter, which is zero because it was starting. And all the results that are zero. But with this tool, you can pretty much get any information about what happens and what's happening on the CC talk bus. That's cool. But, okay. So now I can read on the bus. But, yeah, why not write it down? I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. It writes directly on the same bus. For example, telling the main board, hey, okay. I'm the coin acceptor. I received a new coin. And now a new coin. And now another new coin. That could be pretty great. Oh, God. Sorry. All right. So you see the point. The problem is that you only have one wire for the whole bus. So if, as an attacker, you will If, as an attacker, you will receive the request, the device also receives the same request and responds directly. So if we try to respond just before him or just after him, it won't work. We have many chances that we will jam the signal and make things quite worse. Fortunately, in somewhere deep in the documentation, we have what is called multi-drop commands which is normally used by the control to solve addressing conflicts. Like if you have two or three con acceptors, you can set them different addresses. And it's simply just a comment that you use header 251 address change and you give as a parameter the new address to the device. So you just send that packet and the device will say, okay, fine, now my new address is the one you sent. What is great is there is absolutely no checks made on the device or on the main board that I tested. So you can just connect to the bus and just send one little packet to tell the device to change its address and then you get its address. If I show this, you have the main board there which is address one, the device that's address two, it sends credit read, it sends credit responses, et cetera. I just get on the bus, like I take the address like 77 and just send a packet address change to the device. It will tell the address 99, for example, and I take the address two and the main board will continue to ask me instead of the con acceptor, my status and that way I can respond, okay, I got a new coin. I got a new coin too, again, again, again, again. That's pretty great. But since it's on one wire, you have to be really careful about the timing because if you write something, if the device, another device was also writing on the same bus, it will collide and normally the bus will stop, the machine will reset or they will even be, I could test it, an alarm ringing on the machine and you have to run quickly. I won't say more. So you really have to check for the silence and in the specs it's indicated that the device needs to be pulled every 200 milliseconds. So as the packet needs about 8 milliseconds to be sent, there's normally enough time for us to do. So the thing is to sum it up, to hijack the device, sorry, on the bus, you have to scan this bus to search for a silence period, prepare the injection, create the address change packet, wait for the silence, just send the packet in your silence window and then directly take the address of the device you want to hijack and start respond instead of it. And when you finished, that's also pretty cool to just set the address back so the device is at its old address and you can just leave and everything works. And again, you need to do this while the bus is in use. It's quite complicated. So I created a tool called CC Jack which automates the hijacking process. It cannibulates a device so it scans the bus, it reads every packet that passes on the bus and each packet which is directed to the device you want to hijack, he will record the request and the response. So as soon as he will take over or hijack the device, he will start responding by the last response, the actual real device used to send. So normally it will be pretty much transparent so the main board won't fire an alarm or something like this. It also uses a bus pirate to sniff and inject. And one of the coolest example I have is to inject coins. So as soon as the coin acceptor is hijacked, just start incrementing the counter. As I said, the counter is whenever there is a new event, so just put one coin. If it's accepted, that's okay. Hijack the device and start incrementing the counter and he will see that there is a new event, that is the old one that is a new coin has been inserted, et cetera, et cetera. Another thing that I use also on the same machine is that if there is a glitch, like if the counter value is lower than the one that is set on the main board, there will also be an alarm and again you have to run quickly. So as a demo, sorry, maybe after, I don't know, that's up to you. I'm sorry, I wanted to do a live demo but my coin acceptor just crashed in the speaker room like 20 minute platforms so I only got this loosey video. I hope you will understand it. So what do we have here is a shell obviously and here it's the main emulator that I will use to actually show you what happens. So the tool CCJACK needs several arguments. You give it the interface, the source address of the device to hijack, the destination, so the address you want to send the device to and a time to sniff the packet so it will listen, like I said, it will listen to all the responses, et cetera, and record the new event. I just inserted two strings so I have two credits now and if I send this, I will change the address of the device at address two so the coin acceptor, I will send it to address number seven, it's sent. So now the device, the actual device is on address number seven and I took its place and respond at its place to the main board. If I look at the values, I see that I have actually learned an answer to request 229 so the request, the coin acceptor status and the responses for it's zero one is the counter, zero seven is the coin ID and zero one is that there was actually a new coin accepted. So now what I will do is change the address, let's say, add a 221, I will add two new coins so I will change the payload and now I will have two new credits, great. And what I found also is if I do that again, that will work and normally in the specs, if the counter increments too much like if it increments in 10 to 10, normally it only needs to get the last five results, the one that are actually in the response but as I found in several machine that I tested is that you can just put whatever value, it will just check the last response code so let's put FF as the counter value so we increment by 200 and what happens, no, no, it's afterwards it's another counter that is in the main board, that's only a counter for the coin acceptor, that's it. All right, so since it's nearly over, we'll get to it more quickly, so as the acceptor is offline, so we have ejected it, so we are able to just send commands to it so we can change the validation path so we can just say the path normally that is allowed for the $1 coins, that exists, right? Yeah, okay, so you just tell the coin acceptor to change, to learn a new coin and you set the validation path of the $1 and you just put several quarters or cents, et cetera and it will learn this new coin and when you actually put this new coin, it will send the ID of the $1 and the main board will trade it as $1, so it works, that's great. The other thing that is great is you have several paths for the money, like when the coin is not accepted, normally it will give it back to you so you can trade several times before dropping the coin and you can also change that, so just invert the two so when the coin is not recognized, it will get in the machine and if the coin is accepted, it will get it back to you, so as soon as you win, you just play again, that's great. There are many possibilities and again there are absolutely nothing, no authentication, nothing, you just have to be connected on the bus. Regarding protection and security, there are several things, you can provide a pin code on the device, the only problem is that the pin code needs to be sent in clear text to actually be used, so just sniff the bus, check for header 218, that is provide pin code to a device and just read the four digits that are inside and that's it. You can help by just pulling the power code and boot back the machine and it will actually send the pin code, so yeah, it's in no use. There are also encryption, I didn't actually put a lot of time on this but there are two encryption methods that are used, one is proprietary, it's a 24 bit key, the other one is a desk encryption and they use a pre-shared key between the controller and the device, so you can put it. But the problem is that it's a different header, so you still can request the device using the unencrypted headers and while the machine is in use with the encrypted one, so why not? I just studied that yesterday, I was working in the scissors and there was an open machine, so just to show you exactly where you can see that, you see here the machine is just open here and the bell acceptor is just right here, I don't know if it's a CC talk one, I didn't test it, I wanted to be there and not in jail or something. So it's just there, the connector is just there, so you just can create or put you on the wire, normally it's the fourth one, it should be that red one there, but I'm not sure. So yeah, normally these machines, if they use the CC talk bus, you can just get into them something there. All right, other things, I will get quickly, sorry, other things that might be good points of research is the encryption support, there are many things that I think you can do there because 24 bits is a bit weak. You can also dump the internal memory of devices, you can upload a new firmware on the devices, so you can do pretty much many, many, you can do many things with those and that's just the start. So in conclusions, the specific protocols are quite fun to analyze, it's quite easy, you can find really fun things to do with this. You definitely need to look more in depth in CC talk because since it's money related information, you have interest in applications, right? And just get a bus pirate, it's a fantastic tool for hardware hacking and pretty much all stuff. All the tools are available on my GitHub account and I will post several articles after DevCon on my website, balda.ch. And that's it, many thanks.