Skip to main content
March 30, 2009

Failing to Check Error Conditions Could Get You Sued

The Ontario Lottery and Gaming Corp. is in a bit of hot water after refusing to pay a $42.9 million jackpot:

According to the statement, Kusznirewicz was playing an OLG slot machine called Buccaneer at Georgian Downs in Innisfil, Ont., on Dec. 8 when it showed he had won $42.9 million.

When the machine's winning lights and sounds were activated, an OLG floor attendant initially told Kusznirewicz to go to the "winners circle" to claim his prize, according to the statement. But other OLG employees immediately arrived and told him that the corporation would not be paying, because there had been a "machine malfunction."

They offered him a free dinner for four at the casino's buffet.

In a press release, OLG described the malfunction as follows:

"The single Buccaneer-themed slot machine in question is a two cent per play machine with a base game reward of $300 and an absolute maximum payout of $9,025," the release states.

"The $42 million figure is not a possible award given this machine's configuration and pay table settings."

Of course the lawsuit will probably be thrown out, or OLG will settle with the guy for a lesser amount. But from a technical perspective, it's amusing to think about what happened to cause this scenario. You can imagine the slot machine software looking something like this:

void do_spin() {
  if (winning_combination) {
    unsigned int winnings = calculate_payout_in_cents();
    send_to_display("You've won $%u!n", winnings/100);

int calculate_payout_in_cents() {
  int rv;
  if (rv = lookup_payout_amount())
    return rv;
    return -1;

For some reason, something caused lookup_payout_amount() to return NULL, which meant calculate_payout_in_cents() returned -1, signifying an error. Then, in addition to implicitly casting the signed result to an unsigned type, do_spin() fails to check for the error condition! It assumes success and announces the payout via the slot machine's display. In this case, the -1, represented as 0xFFFFFFFF in two's complement, gets interpreted as an unsigned number, 4294967295, due to the implicit cast, and the display prints "You've won $42949672!"

Today's lesson: remember to check your error conditions!

FREE Security Tutorials from Veracode

Cyber Security ThreatsMobile Phone SecurityFlash Player SecuritySQL Injection AttackCRLF Injection

Veracode Security Solutions

Software Security TestingBinary Code AnalysisApplication Testing

Veracode Data Security Resources

Data BreachesData Loss PreventionData Security

Related Content

Chris Eng, Chief Research Officer, is responsible for integrating security expertise into Veracode’s technology. In addition to helping define and prioritize the security feature set of the Veracode service, he consults frequently with customers to discuss and advance their application security initiatives. With over 15 years of experience in application security, Chris brings a wealth of practical expertise to Veracode.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.