Machine Showing Incorrect Data Compared to Physical Revenue and Transaction Logs
The most common first sign of a gaming machine problem is a data discrepancy: the cash collected from the machine does not match the machine internal counter, or the counter does not match the machine transaction log, or the transaction log does not match the backend report. A discrepancy means that somewhere in the chain of data collection, recording, and reporting, something has gone wrong. The discrepancy could be from a simple counting error, a component fault, a configuration error, or a deliberate attack. Distinguishing between these causes requires tracing the data from its source (the bus signals) through its recording (the machine counter and log) to its reporting (the backend system). A bus-monitoring device provides the source-level data that makes this tracing possible. This article explains how to use bus data to diagnose and resolve data discrepancies at every level of the data chain.
The Data Chain: Where Discrepancies Originate
The data chain from a gaming machine has four checkpoints. Checkpoint 1 — the bus signals: the electrical signals that represent credits, payouts, and other transactions. Checkpoint 2 — the machine counter: the internal register that counts the credits and payouts. Checkpoint 3 — the machine transaction log: the timestamped record of every transaction that the machine stores internally. Checkpoint 4 — the backend report: the summary report that the backend system generates from the machine log. A discrepancy between any two checkpoints indicates a problem between those checkpoints.
A discrepancy between the cash collection and checkpoint 2 (the machine counter) indicates a problem at checkpoint 1 (the bus signals) or at the cash collection procedure. A discrepancy between checkpoint 2 (the counter) and checkpoint 3 (the transaction log) indicates a problem in the counter recording or the log recording. A discrepancy between checkpoint 3 (the log) and checkpoint 4 (the backend report) indicates a problem in the data transmission or the backend processing. The bus-monitoring device provides an independent data source that can verify each checkpoint. The device logs the bus signals (checkpoint 1 data) independently of the machine counter and log. By comparing the device log against the machine counter and log, you can identify which checkpoint is faulty.
Using the Bus Log to Verify Each Checkpoint
Step 1 — compare the device log against the cash collection. The device log records every credit event — the electrical signal that was generated when a coin or bill was inserted. Count the credit events in the device log for the reconciliation period. The count should match the cash collection count, adjusted for the machine cash float. If the counts do not match, the discrepancy is at the cash collection step: the staff may have miscounted the cash, or cash may have been removed from the machine before collection (theft). The device log confirms that the credit signals were generated correctly. The problem is in the physical cash handling, not in the machine.
Step 2 — compare the device log against the machine counter. The device log records every credit and every payout. The machine counter records the net of credits and payouts. The net from the device log should match the machine counter. If the device log net is higher than the machine counter, the machine counter undercounted credits — possible counter manipulation or component fault. If the device log net is lower than the machine counter, the machine counter overcounted credits — also possible manipulation or fault. In either case, the device log identifies which number is correct (the device log, because it records the signals independently) and which checkpoint is faulty (the machine counter). The machine counter can then be inspected for faults or manipulation.
Step 3 — compare the device log against the machine transaction log. The machine transaction log should contain a record for every transaction event in the device log. Missing transactions in the machine log indicate log tampering — someone has deleted transaction records to conceal activity. Extra transactions in the machine log that do not appear in the device log indicate injected transactions — someone has added false transaction records to the machine log. In either case, the device log provides the truth. The machine log is either missing real transactions (tampering) or containing false transactions (injection). The machine log integrity is compromised. The device log should be used as the primary data source for reconciliation while the machine log issue is investigated and resolved.
Counter Manipulation: The Attacker Erasing the Evidence
Counter manipulation is an attack that modifies the machine internal counters to conceal credit extraction. The attacker injects credits (credit injection attack) and then resets the credit counter to its pre-attack value. The cash collection matches the counter because the counter has been reset. The machine appears to have no discrepancy, but the credits extracted by the attacker are not reflected in either the counter or the cash. The attack is invisible to standard reconciliation procedures that compare cash to counter.
The bus-monitoring device detects counter manipulation because it records the credit events independently of the counter. The device log shows the credit injection events followed by the counter reset command. The sequence is: credit injection signal (unauthorized), machine credits the counter, attacker sends counter reset command (unauthorized), counter resets to pre-attack value. The device log records all three events. The machine counter shows no change — the reset erased the evidence. The device log shows the full sequence. The discrepancy between the device log (credit events occurred) and the machine counter (no change) reveals the attack.
The counter manipulation attack is particularly dangerous because it erases the evidence that standard reconciliation would detect. Without the device log, the venue never knows that the attack occurred. The revenue loss is permanent and undetected. The device log is the only defense against this type of attack because the device is the only independent record of the bus events. The machine counter is not reliable because it can be manipulated. The machine log is not reliable because it can be erased. The device log is reliable because the attacker cannot access it — the device is external to the machine and has its own storage, its own clock, and its own access controls. The independence is the reason the device log is trustworthy.
Transaction Log Tampering: The Attacker Deleting the Trail
Transaction log tampering is an attack that deletes or modifies the machine transaction log to conceal specific transactions. The attacker may delete records of credit injection events, delete records of unauthorized payouts, or modify transaction amounts to make the log appear consistent. The tampered log passes the standard reconciliation: the counter matches the cash, and the log matches the counter. The tampering is invisible to the standard reconciliation because the tampered log and the manipulated counter are consistent with each other.
The bus-monitoring device detects log tampering by providing an independent, tamper-evident record of the same transactions. The device log includes every transaction that appeared on the bus. The machine log includes the transactions that the machine recorded. If the machine log has fewer transactions than the device log, some transactions were deleted. If the machine log transaction amounts differ from the device log transaction amounts, some transactions were modified. The comparison is straightforward: line up the device log and the machine log by timestamp, and check for missing or modified entries. The comparison can be automated in a spreadsheet.
The transaction log tampering attack requires access to the machine storage system — typically the hard drive or the solid-state drive. The access may be through the diagnostic port, the machine operating system, or a physical connection to the storage device. The access method determines the countermeasure. Diagnostic port access requires electronic and physical protection. Operating system access requires password protection and access logging. Physical storage access requires cabinet locks and tamper-evident seals. The device log identifies that tampering occurred. The access method investigation determines how it occurred. The countermeasure prevents it from occurring again. The device log is the starting point for the entire response process.
Frequently Asked Questions
Can the bus monitor data be used as evidence in a criminal case against an employee who manipulated machine data? Yes, if the data is properly preserved and the chain of custody is maintained. The device log should be exported immediately upon discovering the discrepancy and stored in a secure location with restricted access. The log should not be modified — do not open it in a text editor, do not re-save it, do not apply any transformations. Preserve the original file. The device manufacturer can provide an expert witness statement that explains how the device generates the log, how the log timestamps are calibrated, and how the log data is protected from tampering. The expert witness statement establishes the reliability and admissibility of the log as evidence. Consult with legal counsel before taking any actions that could compromise the evidentiary value of the log.
What if the discrepancy is from a legitimate component fault rather than an attack? The bus log data will show the fault signature. For example, if the coin acceptor is generating intermittent credit pulses due to a faulty sensor, the device log will show credit pulses with abnormal voltage characteristics — too low, too slow, or too noisy. The abnormal characteristics indicate a component fault. The appropriate response is to replace the faulty coin acceptor, not to investigate for tampering. The bus log distinguishes between attack signals (which have consistent, deliberate characteristics) and fault signals (which have erratic, deteriorating characteristics). The distinction saves the venue from wasting time investigating a fault as if it were an attack.
How often should I compare the device log against the machine data? Daily, if the comparison is automated — for example, the backend system imports both logs and runs the comparison automatically. Weekly, if the comparison is manual — for example, the manager exports both logs and compares them in a spreadsheet. Monthly comparison is insufficient because an attack that starts early in the month may extract significant revenue before being detected at month-end. The daily or weekly comparison minimizes the detection delay and the potential revenue loss. The comparison frequency is a trade-off between security (daily comparison) and operational convenience (weekly comparison). Most venues find that weekly comparison is the right balance — frequent enough to catch most attacks within a few days, infrequent enough to not be burdensome.