Hi, DEF CON. 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 CTS. I love old video games. I love beer. And as I said, I'm a noob speaker,
so if you have any comments, it would be greatly appreciated.
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 searched and I bought a coin 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
different methods to recognize the money.
For the weight, for the size, even visually. And 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 hoppers 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, one dollar, and this tray contains
quarters, the main board will send a command to release four coins.
So you can get your change back.
All of this stuff communicates with several protocols. They are parallel, serial. Another
protocol is MDB and the last one is CC talk. All these protocols are very vendor specific.
So one vendor can do normally only CC talk 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 my con acceptor and it was CC talk
and this is what we will be talking about.
So CC talk 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 those 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 is 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 a UR data transmission so it's
pretty much like a serial communication at 9.6 K, 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, 40 is a coin hopper, et cetera, et cetera. So on the same bus you have all
the devices that can communicate between each other.
A 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. So all the bytes have data.
It depends on what common you will send to the device and a checksum . The
header is the comment that you make.
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 on the bus.
For instance, you have here five, six, seven, eight, nine, ten, twelve, thirteen, fourteen,
fifteen, twenty. So you can see the 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 2 to device at address 1. 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 1, 2, 3 francs,
et cetera.
So in the documentation you have header number 229 that you just sent to a coin acceptor
and you received 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 a coin. The coin was entered.
accepted, was refused, et cetera. 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 of our 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 idea it sends
in the response. So there's a nice trick there. Because since you only have the ID, the coin
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 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 swept. 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 CC protocol on a TNC, a small TNC device.
And it simply pulls a coin acceptor sometimes. And as soon as there is a new coin inserted,
it will send a keystroke to maim the emulator to actually insert the credits in the game.
So here you have the board. There's a Corinth pirate behind, that's because it wasn't
for the bug. There's a TNC right there. The coin acceptor there. And put some money.
Design slash fear比如
The game will see this.最先方 c, the domain value.
And this will send a new crypto. So if I put specific money, if I put straight value
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 are used 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? Cannot
do many anymore. Let me see. Okay. So you can see it. So you can see the data. So you
Maybe if I do this, it's a little bit bigger. Maybe you see better. Sorry. Well, so you
have on the upper side the packets, all the packets list that you can select. And when
you select the packets, 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 raw dump of the
packets. 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 CCTalk packets and responses. Again, if you check the
read buffer codes, so the one used ‑‑ I read the code.
Thank you, everybody. You know the drill. Can I have a lucky audience member volunteer?
You, sir. Well, I just meant you get to watch us.
We have been doing this all day.
All right. Is it your first DEF CON?
No, sir.
Oh, all right. Anyway, cheers.
Cheers.
Cheers.
Yeah, don't worry. We'll see you tomorrow.
Say what?
I don't know.
I have to figure that out. 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 is happening on the bus. That's cool. But
okay. So now I can read on the bus. But yeah, why not write directly on the same bus? Like,
for example, telling the main board, like, hey, okay, I'm the con acceptor. I received
a new coin. And now a new coin. And now another new coin.
That's a new coin. That's a new coin. That's a new coin. That's a new coin. That's a 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 receive the requests. The device also received the
same requests and responds directly. So if we try to respond just before him or just
after him, it won't work. We have many chance 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 okay. It's just okay. It's okay. It's okay. It's okay. It's okay.
Just a comment that you use header 251, address change, and you give 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. And 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
And then you get its address. If I show this, you have the main board there, which is address
1, the device at address 2. 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 us the address 99, for example, and I take the address 2
and the main board will continue to ask me, instead of the coin acceptor, my status and
that way I can respond, okay, hey, 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 come back.
And normally the bus will stop, the machine will reset, or there 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 a
device 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 this packet
in your silence window, and then directly take the address of the device you want to hijack
and start to respond.
Instead of it. And when you're 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 CCJACK, which automates the hijacking process. It can emulate
a device. So it scans the bus. It reads every packets that's passed through the bus, every
is 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,
it 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 examples
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 it will react. So it will start incrementing the counter and it will react. So it 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 con acceptor just crashed in the speaker room, like 20 minutes
before. So I'm going to get this loosey video. I hope you will understand it. So what we
have is ‑‑
obviously. And here is the main emulator that I will use to actually show you what happens.
So the tool CC Jack needs several arguments. You give it the interface, so the bus pirates,
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 events. I just inserted
two constraints, so I have two credits now. And if I send this, I will change the address
of the device at address 2, so the coin acceptor, I will send it to address number 7. It sends.
So now the device
is on address number 7, 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 response is for here, it's 01 is the
counter, 07 is the coin ID, and 01 is that.
There was actually a new coin accepted. So now what I will do is change the address,
let's say, header 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 there are ‑‑ if
it increments in 10 to 10, normally it only needs to get the last five results, the ones
that are actually in the response. But as I found in several machines 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 increment by 200. Okay. So let's just put FF, it will
and what happens? Yeah?
Does the counter decrease when you use credits? So in your video game example,
you play a game, does the counter on the motherboard decrease?
No, no. Afterwards it's another counter that is in the main board. That's only a counter
for the con 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 are ‑‑ we have ejected,
so we are able to just send commands to it. So we can change the value of the con acceptor
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 con 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 change the value of the $1 coin, it will change the value of the $1 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 try it 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 ‑‑ as you win, you just play again. That's
great. Now 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 cord and
boot back the machine.
And it will actually send the PIN code. So yeah. It's 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. It's one is proprietary. It's a 24‑bit key. The other one is a death encryption.
And they use a pre‑shared key between the controls.
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 Caesars. And there was an open machine. So just to show you exactly
where.
You can see that. You see here the machine is just opened here. And the bill
acceptor is just right here. I don't know if it's a CC talk one. I didn't test it. I just
‑‑ I want it 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 the red one. There. But you can just write
but I'm not sure. So, yeah, normally these machines, if they use the CCTalkbus, 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. Many things
that I think you can do there, 24 bits is a bit weak. You can also dump the internal
memory of devices. You can upload a new firmware, so you can do pretty much many, many ‑‑ you
can do many things with those. And that's just the start. 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 CCTalk because since it's money related
information you have interesting 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 DEF CON
on my website, balda.ch.
And that's it.
Many thanks.