Skip to content

Fish Table Machine Score Theft — Why Your Arcade Revenue Doesn’t Match the Data

Fish Table Machine Score Theft — Why Your Arcade Revenue Doesn’t Match the Data

In August last year, a mid-sized arcade operator in Cebu City noticed something that didn’t add up. His eight fish table stations had been running twelve hours a day, packed with players. The system software showed coin-in totals that looked reasonable — about ₱18,000 to ₱22,000 per machine per day. But when the cash collection team opened the boxes on Friday, the actual cash inside was consistently 25% to 35% below what the data predicted. The owner initially blamed his staff. He rotated collectors. He installed a second camera pointed at the cash room. None of it changed the numbers. What finally exposed the problem was a maintenance technician who opened a machine cabinet for a routine power supply swap and noticed a small, unfamiliar PCB wired in parallel with the coin acceptor signal line.

This scenario plays out in arcades across Southeast Asia — particularly in the Philippines and Thailand, where fish table games dominate floor space. The disconnect between reported data and actual revenue is not always a bookkeeping problem or employee theft. It is often a technical compromise of the machine’s scoring system. When the machine thinks a valid credit was inserted, the software logs it. When that signal is spoofed, the software logs it just the same. The cash box tells a different story.

The Problem: Revenue Numbers That Don’t Reconcile

Fish table machines operate on a credit-based model. Players insert cash or tokens, receive electronic credits, and use those credits to fire weapons at on-screen targets. The software tracks every credit added, every shot fired, and every prize awarded. From the operator’s perspective, the metric that matters most is coin-in — the total value of credits loaded into the machine. In a properly functioning system, coin-in should directly correlate with cash in the box, minus payouts.

When the numbers stop correlating, operators typically run through a checklist: counting errors, exchange rate miscalculations, staff pilferage, and software bugs. But in the Philippines market specifically, a growing number of cases trace back to something else entirely: external devices that inject fake credit signals into the system. These devices bypass the physical cash acceptor and tell the machine’s logic board that money was inserted when it wasn’t. The software — dutifully logging what it was told — records the credit. The player gets to play. The owner gets nothing.

Thai operators have reported a related but distinct variant: manipulation of the machine’s stored value tracking. In some installations, technicians discovered that the machine’s internal coin-in counter had been modified to increment at a rate faster than actual credits received, effectively creating a parallel economy where the digital ledger and the physical cash diverged by design. The operator who discovered this in Bangkok calculated his losses at roughly ฿140,000 over a six-week period before the anomaly was caught.

The symptom is always the same: revenue doesn’t match. The cause, as we’re finding, is increasingly technical rather than procedural.

How the Theft Works: A Hardware-Level Explanation

To understand how score theft operates, you need to understand the signal path inside a fish table machine. When a player inserts a banknote, the bill acceptor validates it, determines the denomination, and sends a pulse or serial data packet to the machine’s main controller board. That signal tells the controller: “add X credits.” The controller then updates the player’s balance, logs the transaction, and sends an acknowledgment back to the acceptor.

The vulnerability exists at the point where the acceptor communicates with the controller. On many fish table platforms — particularly older Asian-manufactured units and some current models that use standard protocols like MDB (Multi-Drop Bus) or pulse-based signaling — the communication line is physically accessible inside the cabinet. Anyone with access to the machine interior can tap into this line.

The attack devices we’ve analyzed in the field fall into three categories:

Pulse generators. The simplest variant. These devices connect to the credit input pins on the controller board and emit electrical pulses that mimic the signal from a bill acceptor. The controller interprets each pulse as a valid credit insertion. A basic 555 timer circuit can produce this result. We’ve seen these built into modified cables, hidden inside connector housings, and even integrated into what appeared to be factory-standard wiring harnesses.

Protocol spoofers. More sophisticated. On machines using MDB or similar serial protocols, a microcontroller-based device can impersonate a bill acceptor on the bus. It sends properly formatted data packets — including the denomination byte — and the controller accepts them as legitimate transactions. The spoofing device is typically powered by the machine’s own 12V or 24V rail, so it requires no external battery and can operate indefinitely without detection from the outside.

Memory manipulation. The most advanced method we’ve documented. Rather than injecting fake signals, this approach modifies the credit counter directly in the controller’s RAM or EEPROM. This requires deeper technical knowledge and often involves connecting a programmer to the board’s debug header or ICSP (In-Circuit Serial Programming) port. The modification happens at the memory level, so the controller’s own logging mechanisms may never record a discrepancy.

A technician we worked with in Pattaya pulled a device from a compromised fish table that combined the first two methods. It used a pulse generator for machines running legacy firmware and automatically switched to protocol spoofing when it detected an MDB handshake. The device was the size of a matchbox and had been epoxied to the inside of the cabinet, directly behind the coin acceptor bracket — completely invisible during normal cleaning and maintenance.

What makes score theft particularly difficult to notice is that it doesn’t break the machine. The games play normally. The graphics render correctly. The sound effects work. From the player’s side, there is no indication anything is wrong. From the operator’s side, all they see is a data report that looks plausible but doesn’t match the physical cash. For operators running ten or twenty machines across multiple locations, a 25% shortfall per machine per day adds up to real money very quickly.

How to Detect It: Practical Identification Methods

Detection starts with disciplined record-keeping. If you aren’t comparing your software-reported coin-in against your actual cash collections on a per-machine, per-day basis, you won’t see the gap. This sounds obvious, but a surprising number of operators run aggregate reports — total coin-in across all machines — which can obscure individual machine anomalies.

Here is the detection process I recommend to operators:

Step 1: Establish a per-machine baseline. For each fish table station, record both the software-reported coin-in and the physical cash collected at the end of every operating day. Do this for at least two weeks. Calculate the variance percentage for each machine daily: (reported coin-in minus actual cash) divided by reported coin-in. A healthy machine typically shows a variance under 3%, accounting for payout fluctuations and minor counting errors.

Step 2: Look for pattern deviations. Score theft devices produce specific patterns. Pulse generators tend to show a consistent, predictable shortfall — say, 30% every day, regardless of player traffic. Protocol spoofers often show credit injections during low-activity periods, like the first hour after opening or the last hour before closing, when the perpetrator has access. Memory manipulation may show no pattern at all except the cash shortfall itself. Flag any machine with a persistent variance above 5% for physical inspection.

Step 3: Physical cabinet inspection. Open the machine. Use a flashlight and inspect every cable, connector, and PCB that you don’t recognize. Pay special attention to the wiring between the bill acceptor and the controller board. Look for: non-factory cable splices, any PCB not mounted in a standard bracket, wires that don’t appear in the machine’s wiring diagram, epoxy or hot glue covering components, and connectors that look newer or cleaner than their surroundings. Take photos. If something doesn’t look right, it probably isn’t.

Step 4: Bench test the acceptor-controller loop. If you have a test bench, disconnect the bill acceptor and controller from the machine and run them in isolation. Feed a known number of bills and verify that the controller logs exactly that amount. Any discrepancy in bench testing confirms a problem in the signal chain.

Step 5: Check the software logs carefully. Some software systems timestamp every credit transaction. Look for transactions that occur during hours when the machine should be idle, transactions that arrive at implausibly regular intervals (e.g., exactly every 3 seconds), or transactions with denominations that don’t match the currencies your acceptors are configured to recognize.

In one case in Davao City, an operator found the problem only after I asked him to export his credit logs to a spreadsheet and graph credit insertions by hour. The graph showed a flat line from midnight to 7 AM — except for one machine, which showed a steady trickle of ₱100 credits every two minutes from 1 AM to 4 AM, three nights in a row. The casino-style arcade was closed during those hours. That machine had a pulse generator on a timer circuit.

Prevention: Locking Down Your Fish Table Machines

Prevention works in layers. No single measure stops every attack, but a combination makes your machines a much harder target.

Physical security first. The most direct form of prevention is denying access to the machine interior. Use tamper-evident seals on cabinet doors — the type that leave visible residue or fracture patterns when removed. Number each seal and log the numbers. Require two-person access for any cabinet opening, with both people signing a log. Install cabinet door sensors wired to the machine’s alarm system, configured to trigger a silent alert to management when a machine is opened outside scheduled maintenance hours. These are low-cost measures that don’t require any modification to the game hardware itself.

Secure the communication bus. On machines using MDB or similar protocols, consider implementing encrypted communication between the bill acceptor and the controller. Some current-generation bill acceptors support encrypted MDB, which prevents protocol spoofing by requiring cryptographic authentication of every transaction packet. If your machines don’t support encrypted MDB, an intermediate step is to physically enclose the communication wiring in a sealed conduit or to pot the relevant connectors in epoxy — making unauthorized tapping far more difficult.

Software-side validation. Configure your management software to flag anomalies automatically. Set thresholds: coin-in variance above 5% triggers an alert. Transactions outside operating hours trigger an alert. Rapid-fire credit insertions — more than one credit per 5 seconds from a single machine — trigger an alert. The software can’t prevent the theft, but it can dramatically reduce the time between the first attack and its detection, which limits the financial damage.

Firmware integrity checks. For operators with technical staff, implement a regular firmware integrity verification routine. Compute a checksum of each machine’s firmware and compare it against a known-good baseline. Changes to the firmware checksum indicate either an authorized update or an unauthorized modification — either way, it should trigger an investigation.

Install intrusion detection hardware. Specialized hardware modules are available that monitor the credit input line independently of the main controller. These modules maintain their own credit counter for each input channel and compare it against the controller’s reported figures. A mismatch triggers an alert regardless of what the controller software reports. This provides an independent verification path that cannot be compromised by attacking the controller alone.

In the Philippines, several larger arcade chains have begun retrofitting their fish table fleets with these monitoring modules after calculating that the one-time hardware cost was less than two weeks of undetected score theft at their worst-affected locations. The economics are straightforward.

Frequently Asked Questions

Q: How common is fish table score theft in Southeast Asian arcades?

A: Based on field service records and operator reports across the Philippines and Thailand over the past three years, I estimate that 10% to 18% of fish table machines in high-traffic commercial arcades have been targeted by some form of credit injection or score manipulation. Not all attempts succeed, and not all are ongoing — some are one-time incidents by technicians or former employees. The true prevalence is difficult to measure because many operators attribute revenue shortfalls to other causes and never investigate the hardware. The number is high enough that every operator should include hardware compromise in their differential diagnosis when revenue doesn’t reconcile.

Q: Can’t I just check the daily report from the machine software?

A: The daily software report only tells you what the controller logged. If the compromise injects fake credit signals that the controller accepts as valid, the report will include those fake credits as if they were real. The software report is useful — it gives you the “expected” side of the equation — but it becomes the thing you need to verify against physical reality. If you only look at the software report and never compare it against actual cash collections, you are measuring the controller’s log, not your revenue.

Q: Are newer fish table machines immune to this?

A: Newer machines tend to have better physical security and, in some cases, encrypted communication protocols that raise the technical barrier. But no machine is inherently immune. Attackers adapt. I have seen compromise devices on machines manufactured within the last two years. The key variable is not the age of the machine but whether the operator has implemented layered security — physical cabinet controls, bus encryption where supported, and independent monitoring. A newer machine with no supplemental security is a more attractive target than an older machine with robust protections in place.

Q: Could this be my own staff doing it?

A: In the majority of documented cases, yes — the person who installed the device had physical access to the machine interior, which typically means a technician, a floor manager with cabinet keys, or someone working in collusion with them. External attackers rarely have sustained, undetected cabinet access. This is why access control procedures are as important as hardware defenses. If only one person has cabinet keys and no one else ever inspects the interior, you have created a single point of failure.

Q: If I find a suspicious device, what should I do?

A: First, photograph everything. Multiple angles, close-ups of the device and its connections, wider shots showing its position inside the cabinet. Do not disconnect or remove the device until you’ve documented the installation. Second, note which machines are affected and check all machines at that location — attackers often hit multiple units. Third, preserve the device. It is evidence and also a forensic sample that can help identify whether the same method has been used elsewhere. Fourth, review your access logs and camera footage for the period when the device was likely installed. Fifth, contact a hardware security specialist to analyze the device and recommend specific countermeasures for your machine models. If you want to send us photos and machine model information, we can advise on whether the device matches known compromise patterns.

What to Do Next

If any part of this article resonates with what you’re seeing in your arcade — revenue numbers that don’t reconcile, machines that seem busy but don’t produce, data that looks plausible but feels wrong — the most productive step you can take is a direct physical inspection. Open one machine. Look. Take photos.

You’re welcome to send those photos to us along with your machine model numbers and a brief description of what you’ve observed. I’ve been doing this work for fourteen years, and I’ve seen patterns repeat across hundreds of machines in a dozen countries. What looks like a one-off anomaly in your arcade may match a known compromise method that we can identify quickly.

Don’t wait until the quarterly numbers make the problem undeniable. The machines won’t fix themselves, and the people doing this don’t stop until someone stops them.

Leave a Reply

Your email address will not be published. Required fields are marked *