Tuesday, 28 June 2011

What can be detected and what can not

As of Greasemonkey 0.6.4, however, user scripts now have their own JavaScript context and execute completely separately from the content document. This means that except by noticing changes the changes which they make to the DOM, content scripts can neither detect Greasemonkey scripts, nor interfere with them.


Sometimes, you will want to access the global variables in the content document. For example, maybe the content document defines a function which you want to call. In these cases, you can access the content document's global scope with the unsafeWindow variable. Just be aware that accessing the members of this variable means that content scripts can detect your script and potentially interfere with it if they choose.

Source: http://greasemonkey.mozdev.org/authoring.html

Greasemonkey is becoming more common on casual users computers these days as there are scripts which help you do so many things on so many sites or display things better.  One script for example reformats the BBC news page to look better, another turns non-clickable links on a page into clickable links.  So if a site can detect greasemonkey installed (which greasemonkey developers go out of their way to make it hard) and that a script is active on their page, that in itself is no proof that you are doing something you shouldn't be.  Same if you have iMacros installed, it is a legitmate program used by millions for many tasks.

Some scripts do need to call functions, so although its not straight forward, it does appears it is now possible to detect if a greasemoneky script is being used, depending on what it does and if it changes to the DOM. It is not trivial to do this though.

However.... the above type detection cannot tell you exactly what the script does, which would explain the lack of outright freezings and the way mods are trying to get players to confess.   Harmless scripts that do not help you cheat would show up the same if they access these functions or change certain things.  Other harmless scripts do not use these functions so would not be detectable.  A script that reads your health from the server and displays it in another frame, say closer to where you are reading chat, should not show any different from a script that reads your health for auto-eating purposes.

So to make the detection, code would have been added syrnia server/pages to look for access to the variable. This means that anyone who used scripts in the past but does not now, would not be flagged. This may explain why some high level fighters who I know 100% to have used auto eat scripts have not been frozen, as they are at levels where they wouldn't need to use them anymore at many locations.  So the long term users who got most gains from these kind of scripts have gotten away with it.

In one case, a mod in the multi/chat department was fully aware of a friend cheating (yes I have the proof but have chosen not share it) but obviously did nothing to in order to protect them. Makes you wonder how many mods friends have been protected ;)

I am sure someone is looking at ways of disabling any extra code added to syrnia pages for detection (if there actually is any) or looking at running a local proxy on their machine to stop any attempts at detection.  Google chrome the equivalent of greasemonkey built in, so most scripts would work in chrome without greasemonkey installed.  Some may need a little tweaking to work though.

It is also possible these players did something silly, like running out of food and an auto-eating script still tried to eat.

RULE: 5. 2. User scripts (for example, greasemonkey) are not permitted in Syrnia regardless of their function.

Players would feel its unfair if current mods were caught breaking this rule without being frozen or punished...oh wait don't forget mod RuboxJr being caught red handed!  MadamMasque can try and lay attention elsewhere and call people liars, but the proof was there. Unfortunately you can not fix stupid  :)

window.addEventListener

No comments: