Shoutbox

quote:

---

Originally posted by andrey

quote:

---

Originally posted by ICD

quote:

---

Originally posted by Chrono
lol that's a hell of a lot of clicking, cookie

how many clicks?

---

you spent WAAAAY too much time on that game!

---

lol I don't think he spent that much time on it

quote:

---

Originally posted by Patchou
Note for people like Cookie who would have more than 20,000 clicks on the grid (so basically, to all the cheaters around here )

---

---

A hell of a lot of the clicks are done manually. And with the ones done automatically, I was still at the computer 'monitoring'. I indeed spend an extreme lot of time clicking (manually). 4 hours in a row (with small breaks now and then to eat and drink ) wasn't an exception, while watching tv etc...

(first and second week were done completely manual for example, third and fourth have auto-clicks (but also manual clicks though))

Obviously cookie's is cheated....


I have to ask since the contest is over; How/what method did you use to cheat?

In a nutshell, the program (which I wrote in Delphi) did:

1. load a copy of the gamepic[1].bmp into memory
2. set a variable 'clicked' to false
3. start a timer, which does:
   if 'clicked' is false:
     1. set the cursor to a random location on the grid
     2. compare the RBG-value of that pixel on the desktop to the RGB-value of the pixel in the loaded gamepic.bmp
     3. if it matches: do the mouse click, set 'clicked' to true (and log the coordinates to a file)
   if 'clicked' is true:     
     1. set the cursor to where the 'try again' button should be
     2. compare the RGB-value of that pixel on the desktop to the RGB-value of the 'try again' button on that pixel
     3. if it matches: do the mouse click, set 'clicked' to false   

That was the best way I could think of without sniffing the network traffic, but I guess there are much better ways
The disadvantage was that the mouse was occupied all the time, so I had it reset to it's old position after doing the click, but it was still annoying..
But the advantage was that because I compared the colors, I could select areas that shouldn't be clicked (those areas that were 'hotter' than others in the weekly heatmaps) by marking them on the gamepic[1].bmp.

And yeah, I had to monitor it as well, as it didn't auto-fill the winners form (never got the chance to fill it in anyway )

I really would like to know how cookie did his cheating

Well I cheated by using FireFox and GreaseMonkey.  I had to change something to make it think that Plus! was accessing the site before going into entrance.php and not FF and then my greasemonkey script just replaced a cookie, and select a random position on the grid, it then checked to see if it had already been chosen and would select a new one until it hadnt been chosen.  After it found one then it would send the coordinates and check if the page had the "try again" box (or something like that) and if it did then it would wait a random amount of time (between 1.5 and 3 second i think) before it would try again.

It had lots of random stuff to make it harder for Patchou to detect

quote:

---

Originally posted by riahc4
Obviously cookie's is cheated....

---

How is that "obvious"? In fact, it isn't "obvious" at all though...

If you meant the amount of clicks, that is perfectly doable by spending only a few hours a day clicking. If you mean the spreading of the clicks, you can not see if it is done in a human way or automatic way just by that, read on...

quote:

---

Originally posted by riahc4
I have to ask since the contest is over; How/what method did you use to cheat?

---

Since we didn't know how Patchou would check against cheaters, you had to take some stuff into account (in the end, we all made it way to complicated anyways it seems )...

- He could've monitored the time between clicks. And/or comparing it with the time the map was displayed again. In that way you could easly detect auto-cheators which didn't take in account pauses between clicks or which (like it was suggested in one of the threads) 20 seconds between clicks or whatever.

- He could've monitored the some APIs like Sendmessage, etc which couldv'e been used to do the clicking. However, if the old input APIs were used, you couldn't detect the difference between a manual click and a auto-click (so that is what I used to 'click').

- He could've monitored the mouse movent. Many cheat-tools don't bother to move the mouse. So if he detected the position of the mouse before the click (or even a few positions before that), he could easly detected auto-clicks done by APIs (even with the old input API). So my tool moved the mouse to each point instead of jumping to it. The movement was done like a human, sometimes fast, sometimes slow (but always with a somewhat steady speed). The movement was also not straight to the point but diverted a bit (sometimes big sometimes little).

- He could've monitored the time between the 'try again' screen popping up and the click on the 'try again' button. A human would in most circumstances click the button right away (and not like 20 seconds later or something). The same with the play grid popping up again.

This was easly solved by simply subclassing one of the underlying windows and detecting a WM_PAINT. (although he could've montored for subclassing, but I took that gamble )

- He could've monitored the positions clicked on the 'try again' button. In that way, I think many cheaters would have been detected too as they wouldn't bother to treat the button as a potential detection and just clicked on the same spot or something.

All the above (and some more stuff) was 'solved' by my tool (in VB6 ).


So my tool did (in a small nutshell):
- detect were the game window is (to get its coordinates)
- load the click maps. The different maps were just some big regions too choose from where to click*
- subclass one of the underlying windows.
start the loop:
  - click on a spot
  - start detecting a change.
  - As soon as a change is detected, wait a random of milliseconds and click on a random spot (also with hotspotting build in) on the 'try again' button.
  - start detecting a change.
  - if a change was not detected within 30 seconds it means the click on the 'try again' button wasn't successfull. But that means the button wasn't there, and that means we clicked on a winning pixel and a nice alarm is shown (at this point I could've programmed it to auto-filled in the form, but I cba, I never thought I would win anything with it anyways, which proofed to be true ).
  - start the loop again.



Now, before each click, as well as on the map as on the button, the tool always waited a few milliseconds to a few seconds (a human can not click instantly, and sometimes we want to aim at a certain spot, etc).

But it also could wait longer. This depended on a random time between x and y seconds. Which again depended on the time spend clicking so far. The tool also paused from time to time. We can't click 8 hours in a row, we need breaks, to eat, go to the toilet, a sister who called us away, etc... The tool all did that.


All in all the tool extremely closely simulated human clicking behaviour I think. The only difference (and possible give-away) being the number of clicks. However, this too was well within the reach of a human.

Some people said you could see the difference between a human random clicked map and an auto-random clicked map. This isn't so... If a human clicks realy randomly it produces the same randomness as a robot in the end. And the more clicks done, the less you see any difference. Hotspotting will not occur! (I did plenty of tests with this), unless the human did not clicked in a random way (as many did, because they clicked on the objects in the game picture).

When you see the clicks done on a time scale and see where the clicks are, you could see a difference between a human and a simple random click robot. In that case a human will focus more on big regions (big hotspots), while a robot will click randomly all over the place. My tool made sure that the auto-clicking simulated this same 'hotspotting' over time.

In the end, it wasn't possible to see the difference between a click of this tool and a click of my own (I did clicked a lot myself too). And that is also why Patchou asks me if I cheated or not when I won the tshirt**. At that point I didnt used the tool, but since I had no means to proof it (except for the click-logs), it was my word against his analyzer tool which detected the spreading of the clicks, I think it was only fare to give away the tshirt also because I already had a nice prize from the first week.


* these included non-rectangular regions. The tool stayed in a particular region for a while (a random number between x and y clicks) while occasionally (also based upon random chances) clicking in another map. When a lot of clicks were done it switched to another random region. But this was again done in a random way. Sometimes it switched after only (lets say) 10 clicks, sometimes after spending (lets say) 30 minutes of clicking in that map.


** he also said to me the spreading of the clicks on the candle flames looked far more human. However, most of them were also done by the tool in the same fasion as the rest of the grid. Showing that seeing a difference between human clicks and clicks by the tool just by looking at the end result wasn't water-proof. And I am sure that if I hadn't let the tool click so much, he would never have seen anything wrong.

The tool was made after I won something else (by manual clicking on the grid of course) as an expirement to see how he would detect cheaters and to see how close I could make something simulating a human clicking (which was extremely close I think), and because it was a long while since I programmed anything in VB6

ill say it again, you spent waaaay too much time on that. very clever though, well thought out.

You surprised me Cookie, by checking the data communication to/from the contest server you could have easily ruled out a few of those possible checks . Oh well, fun coding i guess .

Yes and no...

It is not because you don't detect some data when you monitored the traffic when you played, that it wouldn't have been there in case you did cheat... And you don't know that before you make a program which uses APIs etc to 'cheat'.

And there was a lot of data traffic when you played the game anyways, including stuff which I cba to decypher...

By simply using some methods or not using some methods is way more easier and faster than first analyzing data traffic and hoping nothing else is send in case you do cheat... I also wrote all that to show that Patchou could've used a lot more stuff than what people suggested he used to detect cheaters in those other threads about the game, which suggested some methods to cheat (wow, strange sentence ).

Also, the main goal for me was not to actually cheat!, but to make a program which mimics human behaviour, as I'm interested in AI stuff etc and indeed find it fun to make something like that (also the reason why I also simulated mouse movement instead of just 'jumping' to a coordinate). The game was a perfect opportunity for that.

If it was just for 'winning' I could've made the tool a lot easier in the first place.

quote:

---

Originally posted by Nefzen
I think that checking mouse positions would be an invasion of privacy, but meh.

---

How is that an invasion of any privacy??

woa, that's nice deep thought you had there, CookieRevised
I think that checking mouse positions would be an invasion of privacy, but meh.
a friend of mine figured the pack used and simulated clicks, using the contest's cookie, though he was quickly banned a couple of times (different IPs, accounts) when he filled squares