TL;DR This article contains my experiences on testing amusement arcade’s security. I found a DoS vulnerability on Intercard devices. An attacker can take down entire arcade machines by using this vulnerability.

Me and my girlfriend love to spend hours in local arcades. I always wanted to know how their network works and are they secure or not. But I couldn’t find a comprehensive article about it. I decided to test them by myself.

Learning The Fundamentals

In most of the arcades, you need to have their magnetic stripe card. You need to go to the cashier and say how much credit you want. After that, she gets a random card from the stack, swipes it at a machine, presses some buttons on the screen and gives the card.

To play a video game, you need to swipe your card at a machine looks like this:

After a swipe, it tells you how much credit you left and starts the game.

To understand how all these works, I had to look inside those cards and maybe rewrite them. When I was in DEF CON, I bought a magnetic stripe reader/writer and lots of empty magnetic cards from here

When I turned back to Istanbul, I went to the arcade and checked the devices. They were using Intercard machines. I bought 4 different cards.

• Card 1: Has 0 credits
• Card 2: Has 10 credits
• Card 3: Has 20 credits
• Card 4: Has 20 credits

Since I have no previous knowledge about these systems, these cards will answer all of the following questions:

1) Is credit information is written inside the cards as plaintext? If the answer is yes, I will see 0,10,20,20 values in cards.

2) Is credit information is written inside the cards as encoded. If the answer is yes, value of 3rd and 4th cards have to be same, the others will be different.

3) If each card has unique ID? If the answer is yes, all cards have to carry a different value.

I checked the data inside the cards and all of them was different. They were carrying a fixed-size alphanumeric ID value. So there is a server-client architecture inside the arcade. Magnetic reader on the machine sends ID value to the server and server responds with a data which states if I can play or not and how much credit left.

We checked the devices but none of them has ethernet cables. So, they are connected via WiFi. It was a promising attack vector in our case. But, I decided to test everything about magnetic cards before jumping to the Wi-Fi.

Testing For Race Condition

I cloned a card with it’s unique ID which has 20 credits in it. My goal was swiping two identical cards on different machines on the same time to catch a race condition vulnerability. If it works, we can play the second game for free. We tried it in two machines which are both require 2 credits. We swipe the cards on the same time.

First trial: Both card worked. One card showed 18 credits left, second card showed 16 credits left. (Probably we couldn’t swipe at the same time)

Second trial: One card worked, the other showed a generic error. The worked card showed 14 credits left.

Third trial: One card worked, the other showed a generic error. The worked card showed 12 credits left.

At this point, I decided that race condition isn’t possible (or practical) since we always get error on the other card when we swipe at the same time.

Bruteforcing Staff Card’s ID

To configure magnetic card readers, there is a staff card (root access). When staff swipes zher card, zhe can start the game without paying any credit. This card looks same with the customer card. Probably, server keeps the ID value of the staff card, and grants access to the machines by checking that value. So, if I can identify staff card’s ID, I can clone this ID to unlimited amount of cards.

I tried lots of different ID’s such as 00000000 11111111 AAAAAAAA but no luck. If I had Samy Kamkar’s magnetic stripe spoofer I could brute force lots of combinations in short amount of time.

Attempts For Infiltrating The Arcade Network

If we could infiltrate inside the arcade network, we could listen client-server traffic via ARP poisoning. After then, we could search vulnerabilities on communication or in server itself. If their communication isn’t encrypted, we could change “Insufficient credit” response with a positive one.

Capturing and -can’t- Cracking WiFi Handshake

My first plan was conducting deauthentication attack to arcade machines and capture a handshake when they try to reconnect. I used Alfa card with wifite2 tool and it worked. I got a handshake. However, I couldn’t crack it. I tried online websites, run my GTX 1070 graphic card for 5 days but no luck. I’m not sure if Intercard provides router and default password to the stores. If this is the case, they provided a strong password indeed.

Evil Twin Attack

I’m not so good at WiFi hacking but I decided to try another attack that I know. It’s the evil twin attack. My plan was creating fake access point with same SSID of their AP and sending deauthentication packets to arcade machines. After then, they should connect to my AP. If it would work, I could analyze their requests to the main server.

Note : After few months later, I learnt something new about WiFi and realized that this attack would never work. Since the target AP is protected with WPA2 and I didn’t know the password, disconnected devices won’t connect to my fake AP since they won’t be able to do a handshake. Evil twin attack is useful for faking open networks or abusing human behaviour, not for automated machines.

I prepared my laptop and a tool that I can’t remember it’s name for this attack. I could not conduct this attack from outside of the store. I had to create a strong signal to make this work. Because of that, I started the tool, packed my backpack and went inside the store. I picked up medium-crowded hour to not get any attention.

The Chaos

When I walked for 20 seconds inside the store, I was surprised. Most of the machines wasn’t working, people were swiping their cards over and over again. I went to the broken machines and saw these:

At this moment, I was terrified. I realized that my evil twin attack broke those machines. I immediately run away from the store, opened up my laptop and stopped the attack. After 5 minutes, I turned back to the store again. Machines were still broken! Somehow, they couldn’t get IP address.

The DoS Vulnerability

To validate this vulnerability, I went to another store and targeted just one arcade machine with deauthentication packets. I stopped the attack, went inside the store and started to look for a broken machine. I didn’t find any broken machine. After a while, I realized that they are not using Intercard brand but using Embed.

I visited another branch of the arcade which uses Intercard. Conducted an deauthentication attack to a single machine and found a broken one. So this is definitely a vulnerability on Intercard’s side.

I decided not to publish this vulnerability since any attacker may take down an arcade amusement with a laptop and an Alfa card for days, maybe weeks. I tweeted about this. But later on, I’m convinced that this is a problem that Intercard must fix to help their customers. It’s a basic attack, any medium-skilled attacker can find this out.

I sent details to Intercard but couldn’t get any response back. That’s why, I posted this publicly.