Everything went fine until I put in an invalid treasure value which apparently caused some random memory locations to be modified, corrupting the game. Unfortunately, game state was written back to the same floppy disk that holds the game itself, rendering the game unplayable.
Fortunately, I could borrow a second floppy drive, borrow an uncorrupted copy of the game, and repair the game with a disk-to-disk copy. Unfortunately, I plugged in the disk drive connector crooked, sending -12 volts into a chip on the controller board that didn't want -12 volts. The result was a "pop" and a disk controller that no longer worked. Needless to say, my father wasn't happy.
Finding the problem was easy - it was the chip with a square hole blown out of it where the silicon had vaporized. Unfortunately getting a replacement chip wasn't easy when you live in the middle of nowhere. So I built a replacement circuit on a solderless breadboard and wired it into the controller board, and everything worked fine until I could get the proper replacement chip.
TL;DR: cheat at games and you will be punished
TL;DR: cheat at games and you will be punished
And yet I would haver written it, "Cheat at games and you will learn all sorts of cool things." :-)
I would rather say that the moral of this story is: "cheat at games and learn more about computers and electronics than you ever thought possible".
I got into programming through cheating. When I was a little kid I wanted to win at some ZX Spectrum game - Treasure Island Dizzy or something like that. Fortunately, Your Sinclair magazine published a guide on how to PEEK and POKE your way to unlimited lives. That blew my mind, and I credit my interest in the inner workings of computers back to that experience :)
Unlike later games, it was possible to keep leveling up and making money by farming only instead of inviting friends. Plow fields, plant crops, and then harvest them hours later -- repeat as fast and as frequently as you can. TONS of tedious clicking. Of course, I wanted to automate it, and I wasn't alone. Searching around, I found a Perl script that someone had written and I adapted it for my PC.
I just fired up Farmville, and here's what my farm looks like: http://i.imgur.com/nrtkitJ.jpg. It's almost all crops (maximize $) and it requires the farmer to be trapped within hay bales. Otherwise, he walks to where you're clicking and can sometimes get in the way of the click. It would mess up every now and then, but was fairly reliable -- just run the script and let it do its thing for a few minutes. The trick was to flip the game into full screen mode, zoom all the way out, start at a known (x, y) position on your screen's resolution, and then loop through all crop positions by incrementing/decrementing (x, y). Only slightly tricky because of the isometric view and avoiding clicking on some non-crop positions. Picking the right crop was important too, to maximize yield. I just wanted to do two runs a day: first thing in the morning and then in the evening when I got home from work.
I moved up fairly quickly and quit when I beat all of my friends. Got some jeers from those who thought I was actually playing Farmville so much, but had a few requests for said script ...
http://www.autoitscript.com/site/autoit/
Scripting is some dialect of BASIC and also has OCR.
First, I assumed the crops were laid out in a grid without any offsets. This then allowed me to define the grid in a 2d array and mark squares to skip over very easily.
Second, rather than assuming that my cursor is starting at some spot on the screen that I had to keep duplicating, I just start the cursor over the first farm plot.
Third, I actually never move the cursor to a new farm plot position. Instead, I scroll the screen and replace the cursor where it started.
(tl;dr: if it's easy to script your game and win, your game design is busted)
I wrote it up here: http://timotheeboucher.com/on-writing-laconic-error-messages... but the gist of it was that their score submission endpoint required a checksum, but the error message if the checksum was wrong was:
<Response type="error" reason="Checksum failed (ext_csm = cc7ae8d3d26d911f9d6e6178d93b9fc0, int_csm = c1f19e476622b8df7f830ee0c45df533)" server_ver="1.0"/>
What you do with these flagged entries is up to you:-
a) Delete the scores after an hour or so (giving the chance for the user to check things)
b) Only display those scores to the user that logged in
c) Flag the entire account as 'cheat' and ban it after a few dodgy submissions
etc...
1. i.e. expected hash is hash(real_salt+data), supposed expected hash (returned to client in error message) is hash(cheat_salt+data). You obviously never return the real expected hash.
18 U.S.C. § 1030(a)(4)
Whoever— (4) knowingly and with intent to defraud, accesses a protected computer without authorization, or exceeds authorized access, and by means of such conduct furthers the intended fraud and obtains anything of value, unless the object of the fraud and the thing obtained consists only of the use of the computer and the value of such use is not more than $5,000 in any 1-year period . . . shall be punished as provided in subsection (c) of this section.
"Protected computer" in this context means any computer that is connected to the Internet. And the value obtained would be unlimited use of the game, which would normally be a limited. True, that last part is up for debate, as it is possible to play the game without paying, but I wouldn't want to be forced to argue this in court...
One of the things that kept people from snooping around was encryption. All communication went to 1 vaguely named endpoint with 1 parameter, which was a an encrypted list of the parameters and the action to take. This will deter some, but not others.
At the start of a game, the client had to contact the server for a key. This changed each time you played. Any score submission required this key - if it was wrong I ignored it. Only 1 score submission per key.
Note that you have other useful information now: you know how long they were in game to get their score. I flagged scores that were abnormally high for the time it took to get them. I would then review them, and based upon their score history hellban them - they could still play, but no-one saw their high scores except themselves.
If Candy Crush did something similar, they would likely catch you. You wouldn't even know until you gloated and your friends said they can't see your score. Some people who got hellbanned would contact me, and I'd give them a free pass.
Of course you could cheat and get a normal score in a normal timeframe, but I didn't care as much about that.
Beyond trying to thwart cheating, I'm a big fan of cheating in games myself. It's part of why I enjoy eve online so much, because they encourage the usage of 3rd party tools more than any other game I've played.
The most extensive thing I've programmed for cheating is probably a custom MUD client to facilitate multiplay. The clients report to eachother information they know. All clients keep the state of the group and the things I'm fighting. They also keep track of which client can do what, so I can type into any client that I want to heal someone and the program will figure out which client is able to do that, and tell it to do so.
The drawing tool in the game and the anti-cheating systems are both things I created.
I'm impressed with your app. Instead of converting a bitmap to a pixel-by-pixel rendention (which people have done and it looks obvious) it re-draws it like a real drawing, picking one color at a time.
Paying users get a replay feature. It replays fairly realistically and that's difficult to detect as cheating.
Nice work!
Thanks, it's great to hear that from you. I was also going to implement the brush changing logic which would enable it to draw on large areas of single color with a big brush and further optimize other parts to make it even more realistic (detect shapes and draw them completely and draw over them like humans and so) but then I thought, that would ruin the fun. Actually I'm a paying user of the game[0] and never had the intention of ruining the fun for anyone, so I stopped. I'm a big fan of DoD and how it evolved.
Keep up the good work, and thanks for being nice =)
No seriously
Unless people intentionally griefed by creating new low-rating accounts to cheat at.
Step 2: Starbucks Marketing advertises 'Unlimited Candy Crush lives at Starbucks!'
Step 3: Profit! Well, assuming all of the squatters actually buy stuff.
http://blog.thinkgaming.com/is-candy-crush-cheating-will-it-...
Based on the "seed" going back and forth at the start/end of games, I'd have to assume that they are doing something with it. Anyway to see if that's happening?
By the way, if you liked this, there are more posts in that series: http://www.stavros.io/series/winning/
You could be right, but I think the seed is a lot more interesting. If you simply wanted to generate the level, you could use a random number generator on the device and wouldn't care about logging it.
As you showed by varying colors, the candy distribution determines how likely the player is to win, whether they fall just short of clearing the level, etc. This will have a significant impact on whether they pay to continue, buy boosts, etc.
http://www.hung-truong.com/blog/2007/11/07/banished-from-bog...
The most interesting part was the way they decided to do the random generation of letter tiles. At the start of the game, each client was given the same PRNG seed (in the case of Words with Friends, the PRNG was a Mersenne twister), and when tiles needed to be drawn from the bag, instead of having the server tell you what tiles you received, you would use the preseeded PRNG to randomly draw your tiles from the available pool.
Of course, as your opponent is also doing this with the same preseeded PRNG, this also allows you to determine what tiles your opponent has, and what order the tiles will be drawn in for the rest of the game.
Game piracy used to mean stealing the game. Now 'piracy' is getting extra lives.
I expected a similar "hack" with Candy Crush, and was surprised by how "high-tech" their solution is. Good stuff.
Good times
I remember reading an article about some javascript games and how to find the balance for game state server-side check.
source : http://fugiman.com/blog/2013/08/17/on-click-fueled-javascrip...
Anyway, one day a long time after that, I was playing this new mod for Half-Life called Counter-Strike. It was fun, and I had started learning C and about OpenGL to understand a bit more about how HL worked itself. But on this day I saw a guy just running through de_dust getting tons of headshots. Watching his camera, it seemed he had superhuman aiming. Comments about cheating flew, and this was long before the game was infested with cheats. He also seemed to know where everyone was. How?
A few hours later I discovered he was using a cheat called ViperG. It along with another cheat called XQZ were the only known public cheats at the time. ViperG was open sourced on a forum called clientbot at the time. Since I was learning C, I was actually able to read the code. Back then, HL only imported mod client function implementations using DLL imports, so you could write a DLL that exported fake client functions while also importing the real ones from a renamed client.dll, which let your cheat intercept all of the client API calls. Most in ViperG were just pass throughs, but one would gather entity information from a drawing API and another would draw some text on the screen in a HUD update API, etc. It was almost no code but it rendered little '+' signs on every player through walls and would let you automatically aim at their heads. Crazy.
This is when I realized that I could actually take software people had written and break it to make it do whatever I wanted, and that's when I feel like I really started learning things. Understanding how programs ran on my OS and learning how to reverse engineer came pretty rapidly. XQZ was closed source but had some really nice features, so I'd reverse its gl function exports and figure out exactly what it was doing so I could replicate them in my own cheat.
Doing what the author did here for modern MMOs can actually be a very difficult exercise, even for seasoned reverse code engineers. I've done it for several games, essentially reversing the entire netcode to write cheats that automate client actions, and there are all sorts of ridiculous traps I've seen to prevent you from doing so. One game even went so far as to require you to parse a terrain file and send the cell ID of your movement target in every movement packet, along with the absolute coordinates. This was slow as an iterative find process as a map had tens of thousands of triangles and you'd be sending these quite often, so naively you'd just loop over each triangle and check if your target coordinates were inside of it. This gave me a nice introduction into quadtrees and other algorithms that can make this operation asymptotically much faster. Yay learning.
To this day, I can only play a game so much before I get an overwhelming urge to break it. I think that despite the stigma of cheating, it's a great way to learn. It's comparable to taking something apart to see how it works and change it around a bit. Just don't take it too far and ruin games for other people.
But leagues actually made things more interesting. They started creating their own anti-cheats and those were just new shiny toys to break as well. It's quite satisfying to defeat them, even if the goal isn't to cheat in a league.
After 10 days i was number one in the rankings. Scores and amounts of $ was so large that the iphone app was starting to bug... Of course it does not work anymore.
It'll be harder, but not impossible to do (as we've seen by the twitter app API secret leaking some time ago).
Here's a talk I gave on the FarmVille approach: http://www.slideshare.net/amittmahajan/rapidly-building-farm...
and one on the king approach that we're using at my current company: http://www.slideshare.net/amittmahajan/gdc-2013-ditching-the...
In my opinion, with games like this the ultimate goal of the server is to make sure one person doesn't ruin someone else's fun. Seems fine to let them ruin their own fun.
I guess they did it this way because they don't care about people cheating, since pretty much only one person (me) will bother to do it, and it will have no benefit other than their friends being puzzled.
Just look at the leaderboards in iOS Game Center. Top lists are full of cheaters.
There also things like signing each request and such but ultimately, the client can't be trusted and will always be able to cheat in some way (like automating clicks and actions via GUI scripting).
Of course, that doesn't stop the next obvious steps (implementing a full simulation, or controlling the game through the GUI), but neither of those can be stopped.
But luckily in the EU the European court for human rights should stop such stupidity in its tracks.
The only winning move is not to play.
Which brings us to another question - besides hackers, who is interested in cheating these kinds of games? Probably people who want to impress their group of friends who also play the game. I smell a market opportunity here.
Or those who get stuck on one level, and find it more frustrating than fun to keep playing it over and over.
1. skilled enough to hack it AND 2. so interested to play the game that they would pay for something in it
are very very rare.
Unless you have world-wide score list that people actually care about or something like that.
P.S.: It isn't.
I guess it should work here too.
It's also incredibly insightful as a developer to see how crappy code can exist in very expensive software.
http://lwn.net/Articles/132938/
Tridge noted that this sort of output made the "reverse engineering" process rather easier. What, he wondered, was the help command there for? Did the BitKeeper client occasionally get confused and have to ask for guidance?
What’s this? It looks like we can just tell the game we finished a level, without any other hassle