My Machine Randomly Resets Its High Scores — Is This a Glitch or Tampering?

In June 2024, an arcade operator in Guadalajara called me about a fish table machine that kept resetting its high-score table every three to five days. The machine was six months old. The manufacturer said it was a known software bug triggered by a specific sequence of bonus rounds, and they sent a firmware patch. The operator installed the patch. Two weeks later, the high scores reset again. This time, the manufacturer’s support line said they could not reproduce the issue and suggested the operator check for power supply instability. I was called in to look at the machine directly. What I found was not a power supply problem. It was a cheat device that wiped the high-score EEPROM every time it activated, because the device used the same memory space to store its own state variables. The “random” resets were happening on a schedule — every time the cheater played a session of more than 40 minutes, the device’s memory management collided with the high-score storage, and the table cleared. The operator had been looking at a software problem. He was actually looking at a hardware intruder.

This article explains how to distinguish legitimate technical faults from deliberate tampering when your machines exhibit “random” behavior — and why high score resets are a surprisingly common early indicator of compromise.

How High Score Tables Are Stored — and Why That Matters

Most modern arcade machines store high scores in non-volatile memory — either an EEPROM or a section of the main flash storage marked as non-volatile. The purpose is to preserve achievements across power cycles. The high-score table is also one of the few player-visible data structures that persists between sessions. For a cheater who wants to use a machine repeatedly without leaving a visible trail, the high-score table is a problem. It records that a specific machine produced an unusually high score at a specific date and time — exactly the kind of evidence an operator would use to identify an anomalous player.

There are three ways high scores get reset, and they have different implications:

Method 1: Firmware-triggered reset. Some games are programmed to clear high scores after a certain number of plays, or when a specific combination of buttons is held during boot. This is a designed feature, not a bug. Check your machine’s manual before assuming anything is wrong.

Method 2: Power-supply or memory-corruption reset. If the 3.3V rail to the EEPROM dips below a threshold during operation, a write cycle can fail and the table can corrupt or reset. This is a genuine hardware fault. It typically affects other settings too — volume, brightness, audit totals — not just high scores.

Method 3: Deliberate memory wipe by an exploit device. This is the one that matters for this article. Cheat devices that intercept the I2C bus (the communication channel between the main processor and the EEPROM) can accidentally or deliberately erase high-score data. Some do it accidentally because they use the same I2C addresses as the score table. Others do it deliberately to remove evidence of the cheater’s activity.

How to Tell Which One You Are Dealing With

The diagnostic sequence is straightforward if you approach it methodically. I use a four-step process:

Step 1: Check whether other non-volatile settings are also resetting. If your volume settings, brightness, audit totals, and game configuration are all stable, but only the high-score table resets, the problem is specific to the score storage — not general memory corruption. This points to Method 1 or Method 3. If all non-volatile settings reset together, you are likely looking at Method 2 (power supply or PCB fault).

Step 2: Check the reset timing against player activity. A genuine firmware-triggered reset happens on a schedule determined by the game logic — play count, calendar date, or specific in-game events. A cheat-device-triggered reset happens around the time a specific player is active. Review your CCTV footage for the time window when the last reset occurred. Was someone at the machine? Were they doing anything unusual?

Step 3: Inspect the I2C bus for unexpected devices. This requires opening the cabinet and using an I2C scanner (a $3 Arduino or ESP32 can do this) to list all devices on the bus. A clean machine will show only the EEPROM and perhaps a real-time clock. If you see additional I2C addresses that are not in the manufacturer’s documentation, something is attached to the bus that should not be there.

Step 4: Review the audit log for the reset event. Many machines log configuration changes, including high-score resets, in an audit trail. If the reset was triggered through the service menu, the log will show a service-mode entry. If the reset was caused by an I2C bus collision, the log may show a checksum error or memory fault. If the log shows nothing — the reset happened without any service-mode access — that is itself suspicious. It means something outside the normal software flow altered the memory.

Real Cases: When Resets Were Tampering

I have documented this pattern across Mexico, Brazil, and the Philippines. The specifics vary, but the anatomy is consistent:

Case A (Monterrey, Mexico): High scores reset every 4–6 days. Operator assumed power supply issue. I2C scan revealed an additional device at address 0x52 — not in the manufacturer’s documentation. The device was a small module spliced into the I2C line near the main board. It was intercepting score writes and redirecting them to its own storage, effectively giving the cheater “infinite continues” by suppressing score finalization. The high-score resets were memory collisions — the device was not designed to handle the full EEPROM write cycle correctly.

Case B (São Paulo, Brazil): High scores reset after specific player sessions. The operator noticed that the resets always happened on Tuesday and Thursday evenings — the same days a specific player visited. CCTV review showed the player inserting a small device into the service port (an RS-232 port that should have been covered) and running a script that reset the high scores. The player was erasing evidence of their own activity. Once we disabled the service port and installed a firmware update that ignored reset commands from that port, the resets stopped.

Case C (Manila, Philippines): High scores reset randomly — sometimes after 2 days, sometimes after 10. No pattern. I discovered that the machine had a modified firmware that included a “stealth mode” — when activated by a specific button sequence on the player panel, the firmware would wipe the high-score table and then reflash itself to remove the stealth-mode code from memory. The reset looked random because it was trigger-based, not timer-based. The cheater could reset scores at will and then remove all evidence that the capability had ever existed on the machine.

What to Do If You Suspect Tampering

If your diagnostics point toward Method 3, here is the priority sequence:

• Immediately dump the current firmware and save it. If the exploit involves firmware modification, the evidence is in the code. Dump before you power down — some stealth-mode exploits erase themselves on shutdown.
• Photograph all wiring and PCB connections. If there is an I2C interposer or service-port device, you need a visual record before you remove it.
• Check other machines of the same model in your venue. If one machine is compromised, others may be too. I have never seen a cheater target exactly one machine in a multi-machine venue unless they had a specific reason (e.g., that machine was in a camera blind spot).
• Replace the EEPROM. If you suspect the high-score table has been corrupted by an I2C intruder, replacing the EEPROM is the fastest way to get a clean slate. Re-flash the firmware immediately after to ensure the new EEPROM has correct data.
• Update the firmware to a version that includes bus-access controls. Newer firmware revisions for many popular arcade platforms now include I2C address whitelisting — the main processor will ignore any device on the bus that is not in the factory address map. This eliminates the entire class of exploits that rely on I2C interposition.

FAQ

Q: My high scores reset but I found no extra devices on the I2C bus. Could it still be tampering?

A: Yes. Some exploits use firmware modification rather than hardware interposition. The modified firmware can reset high scores through the normal software path — no extra hardware needed. If the I2C bus is clean, dump the firmware and compare its checksum against the manufacturer’s reference. A mismatch confirms firmware-level tampering.

Q: Can I just disable the high-score feature to avoid this problem?

A: You can, but that is treating the symptom rather than the cause. If someone is tampering with your machine’s memory, they are not doing it just to erase high scores. They are exploiting the machine for financial gain. Disabling the high-score display does not stop the exploitation. It just removes one visible indicator that something is wrong.

Q: How urgently should I act if I notice this pattern?

A: Within 48 hours. The longer you wait, the more evidence can be erased by the cheater. In Case C above, the operator waited three weeks before calling me. By that time, the cheater had visited twice more and both times had activated stealth mode — the firmware dump came back clean because the exploit code had self-erased. We never recovered the evidence, though we did stop the losses by updating the firmware and replacing the EEPROM.

Q: My machine is eight years old. Could this just be aging hardware?

A: Possibly. EEPROMs have a finite write endurance — typically 100,000 to 1,000,000 write cycles. An eight-year-old machine that has seen heavy use could have a failing EEPROM that resets intermittently. The way to distinguish this from tampering is to replace the EEPROM and see if the problem persists. If a new EEPROM fixes it, you had a hardware failure. If the resets continue with a new EEPROM, something is actively causing them.

Q: Should I report this to the manufacturer?

A: Yes. If you confirm tampering, the manufacturer needs to know so they can issue patches or hardware bulletins. Many arcade firmware updates are triggered by exactly these kinds of field reports. The manufacturer may also be able to tell you whether the specific exploit method you encountered is one they have seen before — which tells you whether it is a widespread problem or a targeted attack on your specific venue.

What to Do Next

Start by documenting the reset pattern. Note the date and time of the last three resets, cross-reference them against your CCTV footage, and check whether the same player or staff member was present for multiple reset events. Photograph your EEPROM and main board thoroughly — especially any wiring that connects to the EEPROM socket. If you are not comfortable opening the cabinet and scanning the I2C bus yourself, send the photos to your distributor or a technical consultant and ask for a remote assessment. The key is to act on the pattern, not to wait for it to become obvious. Most memory-based exploits are detectable for weeks before they become financially catastrophic. The window is there — but only if you look.