What gives with these velocicarmageddon high scores?
May 26, 2008 8:16 PM Subscribe
OK - this is stupid, but how on earth did these people get such high scores on Off-Road Velociraptor Safari? I got 1,000,000 points once when the game crashed mid-jump, but I can't fathom how these guys got scores in the billions!
Cheating, probably. There is no way to prevent it if you let people run the actual simulations on their own computers, as this game does.
The best a developer could do would be to require that high scores are submitted along with the keystrokes required to achieve that score; the score could then be verified by running the keystrokes through their own copy of the game. However, this would not prevent cheating by things such as savestates, slow motion, computer control, and the like.
posted by Pyry at 8:28 PM on May 26, 2008
The best a developer could do would be to require that high scores are submitted along with the keystrokes required to achieve that score; the score could then be verified by running the keystrokes through their own copy of the game. However, this would not prevent cheating by things such as savestates, slow motion, computer control, and the like.
posted by Pyry at 8:28 PM on May 26, 2008
Response by poster: ok - I haven't been able to find any cheats. Can anyone point me in the right direction?
posted by sfz at 8:29 PM on May 26, 2008
posted by sfz at 8:29 PM on May 26, 2008
Worth noting that the leader on the scoreboard's score is 2,147,483,647 = 2^31 = 2 147 483 648 - 1. This is exactly the upper bound for a signed 32-bit integer. I'm guessing it's the highest possible score in the game.
Almost definitely hax. Most likely they figured out the submit mechanism.
posted by kdar at 8:34 PM on May 26, 2008 [4 favorites]
Almost definitely hax. Most likely they figured out the submit mechanism.
posted by kdar at 8:34 PM on May 26, 2008 [4 favorites]
Here are two possibilities for cheating (I'm not about to install some random plugin for a single game):
1) This works if it is using http requests to submit high scores
2) If it's doing something more complicated (direct UDP?), you'll have to use a packet sniffer, or you might try changing your score in the game directly with a memory scanner like the cheat engine.
posted by Pyry at 8:46 PM on May 26, 2008
1) This works if it is using http requests to submit high scores
2) If it's doing something more complicated (direct UDP?), you'll have to use a packet sniffer, or you might try changing your score in the game directly with a memory scanner like the cheat engine.
posted by Pyry at 8:46 PM on May 26, 2008
it takes about 10 seconds (literally) to set your score to whatever you like in games like these, if you have any game hacking experience. online leaderboards for almost all games run on the client side are worthless unless it's on a locked-down, uncracked platform (xbox 360 and PS3 right now) and uses good encryption for communication back to the server.
posted by tumult at 9:13 PM on May 26, 2008
posted by tumult at 9:13 PM on May 26, 2008
there is or at least was a little program called poke... It'd let you punch in a value and it would search for the memory location for it. So if the score is 30 you'd punch in 30 and it'd tell you all the memory addresses that contain 30. If you get more than one at 30 you'd get some more points in the game and then punch that it and further narrow it down.
Once you know where it is the program would let you set it to what ever you want or freeze it at a value. I remember it working for tons of different programs.
posted by magikker at 9:33 PM on May 26, 2008
Once you know where it is the program would let you set it to what ever you want or freeze it at a value. I remember it working for tons of different programs.
posted by magikker at 9:33 PM on May 26, 2008
The only reason this is easy is because the developers were lazy about how they send the data. If they salted the high score reports (ala this old askmefi thread on web security) this would be much harder to do.
Tools that actually manipulate local game state will still work, though. I always assumed these kinds of attacks were always on the high score submission engine on the server, but the memory/time manipulation tools sound very sneaky.
posted by heresiarch at 6:39 AM on May 27, 2008
Tools that actually manipulate local game state will still work, though. I always assumed these kinds of attacks were always on the high score submission engine on the server, but the memory/time manipulation tools sound very sneaky.
posted by heresiarch at 6:39 AM on May 27, 2008
Best answer: So I did the web integration on Raptor Safari (along with the physics setup/tuning and some other stuff). I've been lazy lately on clearing the leaderboards of bogus scores, but only because we'll be moving all of our games to a central website soon. When this happens we'll increment the version ID on the scores, which will essentially clear everything except the "all-time, all-version" list.
Backend HTTP POSTs are salted, and somewhat obfuscated, so I doubt people are bothering to hack it there. The scores are almost certainly in-memory changes while the game is running; then the client just sends the score along, proper hash and all. When we move the game over to the new site I'll look at blocking a few of these. It's definitely an arms race, though, and not a very productive use of time to match mischievous players move for move, but any low hanging fruit will be taken care of.
The unified site will launch just as soon as Jetpack Brontosaurus is complete...
posted by matthewwegner at 9:21 AM on May 27, 2008 [9 favorites]
Backend HTTP POSTs are salted, and somewhat obfuscated, so I doubt people are bothering to hack it there. The scores are almost certainly in-memory changes while the game is running; then the client just sends the score along, proper hash and all. When we move the game over to the new site I'll look at blocking a few of these. It's definitely an arms race, though, and not a very productive use of time to match mischievous players move for move, but any low hanging fruit will be taken care of.
The unified site will launch just as soon as Jetpack Brontosaurus is complete...
posted by matthewwegner at 9:21 AM on May 27, 2008 [9 favorites]
One thing you could do if you wanted to prevent make it much more difficult would be to use a two-way function to store the score in memory. You could have another score 'in memory' to be displayed on the screen, but use AES (or something) to store the original score. You could also keep a bunch of 'copies' of the score in random places in memory to make debugging more difficult.
But, in theory there is no real way to prevent fake scores from the truly dedicated.
posted by delmoi at 5:57 AM on May 28, 2008
But, in theory there is no real way to prevent fake scores from the truly dedicated.
posted by delmoi at 5:57 AM on May 28, 2008
You could ensure that all randomized game elements were generated from a seed sent by the server, and then huffman encode the user's inputs (i.e. at game clock cycle one, the user pressed the space bar, at cycles two through 50, the user pressed no keys), send that over when a level is done, and then simulate the game on the server side (with a faster game cycle) to obtain the score. That way, the only way to send a valid score over to the server is to play the game.
Now this doesn't account for people slowing down the game itself, although you could ensure that all seeds and user inputs are sent and received in a reasonable amount of time.
But now you've got the situation where people could save what is sent over by the game to the central server and allow others to download the run-throughs of the game.... this one I'm having trouble with. You could store hashes of the game play encodings being sent, and disallow any that hit the same hash position -- assuming that the game play is complicated enough. Also note, that people can download good gameplay run-throughs anyways even if the score sending mechanism was 100% secure.
There's nothing short of having people watching you play and then report the score to the server by themselves that would 100% solve this problem.
posted by sleslie at 7:59 PM on May 28, 2008
Now this doesn't account for people slowing down the game itself, although you could ensure that all seeds and user inputs are sent and received in a reasonable amount of time.
But now you've got the situation where people could save what is sent over by the game to the central server and allow others to download the run-throughs of the game.... this one I'm having trouble with. You could store hashes of the game play encodings being sent, and disallow any that hit the same hash position -- assuming that the game play is complicated enough. Also note, that people can download good gameplay run-throughs anyways even if the score sending mechanism was 100% secure.
There's nothing short of having people watching you play and then report the score to the server by themselves that would 100% solve this problem.
posted by sleslie at 7:59 PM on May 28, 2008
sleslie:
True, and I think this is a great solution for anything like a competitive bridge builder-style game. Unfortunately, the physics system in Raptor Safari--PhysX--isn't deterministic. It would be difficult for us to simulate a game on the server. Plus, we've had 535,672 games played to date, which is creeping up on nontrivial to process.
We do actually have a record of every scoring event in the game: the type of score, its XYZ position, and when it happened in the game's timeframe. I haven't done anything with it yet, but it's 15.4 million records of juice data waiting to mined. Would be fun to heat map...
I'll try a few things in the next update to discourage simple cheating, but in the end it's probably just as much time to code things as it would be to manually remove offending scores.
posted by matthewwegner at 1:31 PM on May 29, 2008
True, and I think this is a great solution for anything like a competitive bridge builder-style game. Unfortunately, the physics system in Raptor Safari--PhysX--isn't deterministic. It would be difficult for us to simulate a game on the server. Plus, we've had 535,672 games played to date, which is creeping up on nontrivial to process.
We do actually have a record of every scoring event in the game: the type of score, its XYZ position, and when it happened in the game's timeframe. I haven't done anything with it yet, but it's 15.4 million records of juice data waiting to mined. Would be fun to heat map...
I'll try a few things in the next update to discourage simple cheating, but in the end it's probably just as much time to code things as it would be to manually remove offending scores.
posted by matthewwegner at 1:31 PM on May 29, 2008
This thread is closed to new comments.
posted by amyms at 8:27 PM on May 26, 2008