Hacker News Reader

Comment by withinboredom | Hacker News Reader

Huh. Reminds me of my favorite idea to "hack" the lottery:

1. get access to a lottery ticket terminal

2. get access to a router firmware in the lottery datacenter en route to the database

3. wait for the query to get the winning numbers from the database

4. hold that packet and submit an INSERT into the database with you as the winning number at a predetermined date/time in the past

5. release the packet to query the database

6. hack the terminal to print your winning ticket with the predetermined date/time in the past

7. profit?

It probably doesn't work, but it was fun thinking about when I was younger.

View on HN

Most lotteries, all of them that I'm familiar with, blackout ticket sales for several minutes around the draw to avoid order sensitivity issues like this. It's funny, lotto vending machines here don't say when the drawings are for each game, but you can tell by reading the fine print for the five minute window where tickets are not sold.

Step 6 of this process was to subvert the machine and print a backdated ticket. How does blacking out ticket sales for five minutes around the draw help against that?

Presumably all ticket sales (including their numbers) are synchronously reported to the lottery office by the sales terminals. That would render backdating attacks detectable.

Yes - in Australia's lotto system at least, the physical tickets are inserted into the database then printed once they are confirmed to be committed.

Yeah, I imagine they save the list of all the tickets they've sold, get a hash of the values, and then generate the winning number.

The backdating is trivially detectable unless you manage to get the database operations to happen the wrong way around, which is why the whole "holding a packet" thing has to happen. But part of the reason for the blackout period is to account for the possibility of that kind of thing happening anyway.

If you have to fake the issue time by five minutes, then 1) the described method is probably infeasible anyway because the connection to the database will time out while the packet is held for multiple minutes, 2) the ticket issue date and audit date on the database event will vary by at least five minutes which makes it obvious that the ticket was improperly issued.

>2. get access to a router firmware in the lottery datacenter en route to the database

Seems non-trivial given that the database server is likely to be in the same datacenter/rack/physical machine. If you have this much access you might as well plant a backdoor in the server and tamper with the database however you want.

>3. wait for the query to get the winning numbers from the database

Are lottery winners determined immediately after they close? I thought they did a number picking ceremony by picking out literal number balls from a tumbler?

They usually stop sale an hour before the ball-picking, at least around here.

I assume that hour is for all the "picks" to be transmitted up to them for record keeping.

In Australia at least the balls are drawn an hour later.

No idea about the computer RNG games though.

> submit an INSERT into the database with you as the winning number at a predetermined date/time in the past

If you have this capability then why not just insert all number combinations into the db well before draw time?

Makes me wonder how money flows from lottery terminals back to the lottery itself. I imagine there's some rigorous bookkeeping involved.

Because you'd also have to submit the money it would cost to buy every combination, and also, you likely couldn't fit every ticket (tens of millions of combinations) with a realistic-looking ticket generation time (approx 1-5 seconds between each ticket created). i.e. if 50,000,000 tickets all had the same timestamp (or were off by nanoseconds) it would be a dead giveaway.

In the Ethereum blockchain, some people do exactly this - for more details, search "miner-extractable value".

I don't know whether it still applies after the transition to proof-of-stake.

MEV still applies with proof-of-stake. Whoever proposes the blocks can make those arbs. It used to be the miners; now it's the block proposers as selected by the beacon chain.

(Some people call it "maximal extractable value" now, to keep the initialism and help it make more sense.)

Tldr- about 20 years ago, when off-track betting systems were less sophisticated, an insider past-posted horse racing jackpot winners by waiting until the first 4 races of the Pick-6 were final before creating the ticket. They got busted and served time in federal prison because they had multiple winning tickets for the Breeders Cup Pick-6, basically the Super Bowl of horse racing, where scrutiny was extremely high.

https://en.m.wikipedia.org/wiki/2002_Breeders%27_Cup_betting...

> hack the terminal to print your winning ticket with the predetermined date/time in the past

If the terminal is not a dumb gateway to the central service, that would be a massive risk. I'd be extremely surprised if that was possible.

I mean, you could probably still print something, but any validity check would fail.

Reply on news.ycombinator.com