My Fish Table Machine Shows Different Numbers Than the Central Server — How?

In early February of this year, a multi-location gaming operator based in Dubai contacted me with a problem that had been troubling his accounting team for nearly two months. He runs six fish table machines across two venues, all connected to a central server that aggregates play data, credit consumption, and revenue figures. His accountants had noticed a persistent discrepancy: the physical cash collected from the machines at one venue was consistently 18% higher than what the central server reported as credits consumed. The numbers on the machine displays matched the cash collected. The server records showed lower figures. For a business processing approximately 45,000 AED in weekly credit transactions, an 18% gap represented roughly 8,100 AED per week — over 32,000 AED per month — that was simply disappearing from the server-side accounting records. The operator initially assumed a software bug and contacted the game manufacturer for a patch. When the patch did not resolve the issue and the gap continued widening over the following weeks, he realized he was dealing with something else entirely. Someone had inserted themselves between the machines and the server.

The Symptoms: What You Notice When Machine and Server Numbers Don’t Match

The most visible sign is the reconciliation gap itself: money collected versus money recorded. But this symptom rarely appears in isolation. Operators who look closely typically find a cluster of related anomalies. The machine’s local credit meter shows one number. The server’s record for the same machine over the same time period shows a different number — consistently lower, and the gap is not random. It follows a predictable pattern.

In the Dubai case, the operator also noticed that certain high-value transactions were missing entirely from the server logs. When a player loaded 500 AED worth of credits at the machine, the local display registered the full amount. But the server record for that same time window showed either a smaller amount — 300 AED loaded, 200 AED loaded — or occasionally no record at all. The pattern became even more specific: transactions processed during a particular four-hour window in the afternoon, between 2 PM and 6 PM, were the ones most likely to be underreported. Outside that window, server records and machine records matched within 2-3%, which is within normal communication latency tolerances.

A third symptom appeared in the network traffic logs after the operator’s IT team began monitoring. The machines communicated with the server over a standard TCP/IP connection on port 8090. The IT team observed that data packets sent from the machines to the server were being acknowledged by the server, but the acknowledgment packets were arriving at the machines with an unusual latency pattern — consistently 85 to 120 milliseconds of additional round-trip time compared to baseline network latency. During the unaffected hours, round-trip time was 5 to 8 milliseconds. During the affected window, it was 90 to 130 milliseconds. That 100-millisecond penalty is a classic signature of a man-in-the-middle relay.

Operators at other Middle East locations have reported variations of this pattern. A Sharjah-based operator noticed that his server reconciliation reports showed credits being transferred between machines that were in physically separate venues five kilometers apart — transfers that supposedly happened within seconds of each other. The machines were not networked to each other directly; they only communicated with the central server. Someone had injected fabricated transaction records into the data stream, and the server was accepting them as legitimate because they appeared to come from authenticated machine IDs.

The Technical Mechanism: How Data Gets Altered Between Machine and Server

Fish table and multiplayer gaming machines use a client-server architecture where each machine station acts as a client that reports transaction data to a central server. The communication protocol varies by manufacturer, but most systems built in the last decade use either a proprietary binary protocol over TCP or a REST-style API over HTTP. Some newer installations use WebSocket connections for real-time game state synchronization. In all cases, the machine sends structured data packets containing transaction type, amount, timestamp, machine ID, and session identifiers. The server processes these packets, updates its database, and sends back an acknowledgment.

The man-in-the-middle attack exploits the fact that most arcade network installations use simple local area network topologies with minimal network segmentation. A typical setup routes all machine traffic through a single network switch connected to the back-office server. The cheater inserts a device — often a small single-board computer like a Raspberry Pi or a repurposed router running custom firmware — between the machine bank and the server. This device operates as a transparent proxy: it receives data packets from the machines, modifies them, and forwards the modified versions to the server. The server sees what appears to be legitimate data from an authenticated machine. The machine sees what appears to be normal acknowledgment from the server. Neither endpoint detects the interception because the proxy device is transparent at the TCP level.

What happens to the data inside the proxy depends on the cheater’s objective. In the Dubai case, the proxy was reducing credit amounts in the server-bound packets. When a machine reported a 500 AED credit load, the proxy changed the amount field to 300 AED before forwarding. The 200 AED difference was then extracted from the machine through a separate mechanism — typically a collaborator with physical access who withdraws credits from the machine as cash-equivalent payouts. The server record shows 300 AED consumed. The machine’s local record shows 500 AED loaded. The physical cash matches the machine’s record. The server is short by 200 AED. The cheater walks away with the difference.

In other cases I have documented, the attack focuses on game outcome manipulation rather than direct credit theft. The proxy intercepts server-to-machine communication and modifies game result data in real time. A fish table that should have reported a 5,000-point multiplier win to the player instead receives a modified result packet showing a 50,000-point win. The server never records the inflated payout because the modification happens between the server and the machine. The operator only discovers the problem when the machine’s local payout records are compared against server logs and the discrepancy becomes too large to ignore.

The technical barrier to implementing these attacks is moderate but not prohibitive. A person with basic networking knowledge, access to online tutorials, and approximately $50 in hardware can build a functional transparent proxy. The more sophisticated part is understanding the proprietary protocol well enough to modify packets without breaking the checksum or sequence numbering, but most arcade protocols lack cryptographic integrity protection that would prevent undetected modification. CRC checksums and simple sequence counters are not security mechanisms — they are error-detection mechanisms that anyone can recalculate after modifying the payload.

How to Determine Whether Your Machine-Server Communication Is Being Intercepted

Start with a structured reconciliation process that goes beyond comparing totals. Export server transaction logs and machine-local transaction logs for the same 24-hour period and compare them line by line — every individual transaction, not just the daily sum. Look for three specific patterns: transactions that appear in the machine log but not in the server log, transactions where the amount differs between the two records, and transactions where the timestamp differs by more than 10 seconds. Any of these patterns in quantities that exceed occasional network errors indicates active interference.

Network latency analysis is a powerful diagnostic tool that most arcade operators overlook. If your machines ping the server with 3-5 millisecond round-trip times under normal conditions, any consistent increase to 20+ milliseconds during specific time windows suggests that traffic is being routed through an intermediate device. Use a continuous ping monitor running on the server that logs latency to each machine IP address every 60 seconds. Graph the results and look for step changes in latency that correlate with specific times of day. The additional processing delay introduced by a transparent proxy is usually 5 to 20 milliseconds per packet — not enough to cause obvious lag in game play, but clearly visible in latency graphs.

Physical inspection of the network infrastructure is essential. Follow the Ethernet cables from your machines to the switch. Is there any device connected between the machine and the switch that you did not install? Small inline devices that sit directly on the Ethernet cable — sometimes called Ethernet taps or hardware proxies — can be as small as a matchbox. They are powered either by Power over Ethernet or by a small USB power adapter plugged into a nearby outlet. Look for any unfamiliar device connected to your network switch, any Ethernet cable that splits into two connections through an adapter, or any small computer or router tucked behind cabinets or under desks near your machine installation.

Check your switch’s MAC address table. Most managed switches allow you to view which MAC addresses are connected to which ports. If you see multiple MAC addresses on a port that should only have one machine connected, that port has an additional device attached — potentially a proxy device bridging between the machine and the switch. Also check for promiscuous mode indicators on your network interfaces. Some switch management interfaces can flag ports where the connected device is operating in a mode that captures all traffic, which is typical behavior for interception devices.

Protocol-level detection requires more technical effort but provides definitive evidence. Use a network protocol analyzer — Wireshark is the standard free tool — to capture traffic between one machine and the server for 30 minutes during a period when you suspect manipulation. Compare the raw packet contents captured at the machine side against the server’s received data. If the server is receiving packets with modified payload contents, you will see different data values between the two capture points. The specific differences tell you exactly what data the proxy is modifying.

Steps for Preventing and Resolving Server Communication Manipulation

The single most effective measure is network segmentation. Your gaming machines should be on a physically separate network from general office computers, guest Wi-Fi, and any other devices. Use a dedicated switch for the machine network with no connection to the internet except through a controlled firewall. If someone needs to access the machines remotely for maintenance, use a VPN with strong authentication rather than exposing machine IP addresses directly. Physical separation eliminates the attack vector where a cheater gains network access through the public Wi-Fi and pivots to the machine network.

Encrypt machine-to-server communication if your game platform supports it. TLS encryption does not prevent all forms of manipulation — a proxy with access to the machine’s TLS keys can still decrypt and modify traffic — but it raises the technical barrier substantially and prevents casual eavesdropping. If your current game software does not support encrypted communication, ask your manufacturer whether a firmware update can add it. For custom or older systems that do not support encryption, consider tunneling the traffic through a VPN connection between each machine and the server, effectively encrypting the communication at the network layer rather than the application layer.

Implement transaction sequence numbering with server-side validation. Each transaction from a machine should include a monotonically increasing sequence number. The server should track the last sequence number received from each machine and reject any transaction with an out-of-order or duplicate sequence number. This prevents replay attacks and makes it impossible for a proxy to inject fabricated transactions without the server immediately detecting the sequence gap. Sequence numbers should be stored in non-volatile memory on the machine so they persist across reboots.

Automate reconciliation. Do not wait for monthly accounting to discover discrepancies. Set up a script or monitoring system that compares machine-local totals against server totals every hour and alerts you when the difference exceeds a threshold — something like 2% or 50 AED, whichever is higher. The alert can be a simple email or SMS notification. The key is catching the discrepancy within hours rather than weeks. When you detect it quickly, you can investigate while the evidence — physical network configuration, proxy device location, timing patterns — is still present.

For operators who have already confirmed interception, the resolution steps are: first, physically disconnect and inspect every network cable and device between the machines and the server. Remove any unauthorized hardware. Second, change all administrative passwords on the server, machines, and network equipment. Third, reflash machine firmware to factory defaults in case the attacker installed persistent software on the machine itself. Fourth, implement the network segmentation and monitoring measures described above before reconnecting. Fifth, conduct a full audit of all transaction records to quantify the total loss and identify any patterns that may suggest the attacker’s identity or methods.

Q: Can someone intercept machine-server communication without physical access to the network?

A: Physical access makes interception significantly easier, but it is not strictly required. If the machine network is connected to the internet and the attacker can compromise the server or network equipment remotely — through default passwords, unpatched vulnerabilities, or phishing — they can install proxy software directly on the server or on a compromised device on the same network. In one case I reviewed from a venue in Abu Dhabi, the attacker had compromised the router through a default admin password and installed iptables rules that redirected machine traffic through a proxy process running on the router itself. No additional physical hardware was required.

Q: Will my game manufacturer’s software detect these attacks automatically?

A: Most game platforms include basic error checking — CRC fields, sequence numbers, timeout detection — but these are designed to detect network errors, not deliberate manipulation. A person modifying packet contents can also recalculate the CRC to match the modified data. Few arcade game platforms include cryptographic authentication of transaction data such as digital signatures or HMACs that would prevent undetected modification. Unless your platform specifically advertises end-to-end data integrity features with cryptographic protection, assume that the software cannot detect sophisticated interception.

Q: How do I know if the problem is a software bug versus deliberate tampering?

A: Software bugs produce random or uniformly distributed discrepancies. Deliberate tampering produces discrepancies that follow patterns — specific time windows, specific machines, specific transaction types or amounts. A bug that causes 18% data loss would affect all hours of operation roughly equally. Data manipulation that happens almost exclusively during a four-hour afternoon window when a specific employee is on shift is almost certainly deliberate. The timing pattern is often the most reliable differentiator between a bug and an attack.

Q: What should I look for during a physical network inspection?

A: Walk the entire cable path from each machine to the switch or server. Look for any inline device — anything with an Ethernet port that sits between the cable and the wall jack or switch. Common interception hardware includes Raspberry Pi boards with USB Ethernet adapters, small travel routers running OpenWRT, and purpose-built Ethernet taps that are about the size of a USB flash drive. Also check power outlets near your machines and server rack for unfamiliar USB power adapters — proxy devices need power, and a USB charger plugged into a wall outlet near your network equipment is a strong indicator.

Q: After removing the proxy device, do the numbers automatically return to normal?

A: New transactions after removal should match, but the historical records remain discrepant. You will need to reconcile past data manually or through a script that identifies and corrects the modified records. The more important concern is whether the attacker installed any persistent software on the machines or server during the period of access. I recommend reflashing machine firmware to factory defaults and reinstalling the server operating system before considering the incident fully resolved. The proxy device is the visible symptom; the attacker’s access to your network is the root cause, and you need to address that comprehensively.

What to Do Next

If your reconciliation numbers are not matching and you have ruled out simple accounting errors, begin with the network latency test I described. It costs nothing, takes 24 hours of logging, and provides immediate diagnostic value. Simultaneously, document every instance of the discrepancy: which machines, which times, which transaction types, and the specific amounts involved. This documentation is essential both for quantifying your loss and for identifying the pattern that points to the attack mechanism.

Photograph your network setup — the switch ports, the cable routing, any devices connected near the machines — and keep those photographs as a baseline for future comparison. When something changes in the physical infrastructure, you have a reference point. If you have packet capture capability, save a 30-minute traffic sample during a normal period for comparison against suspicious periods.

If you need help interpreting network logs, transaction records, or physical inspection findings, send the data along with a description of what you are seeing. I have analyzed dozens of server reconciliation cases across different game platforms and network configurations, and the patterns tend to repeat. Sometimes the issue is simpler than it appears, and sometimes it is more organized than you expect. Either way, ignoring the gap will not make it close on its own.