How to make our scripts practically undetectable?
1,596 views
Skip to first unread message
Calmarius
Aug 25, 2009, 5:46:34 AM8/25/09
to greasemonkey-users
Some site authors does not like userscripts running on their sites
(especially the authors of browsergames).
Scripts can be detectable if a scheduled js function check the dom and
the window object for modifications.
I've written a simple demo for this:
The page:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd">
<html>
<head>
<title>GM sucker page!</title>
<script>
function checkDOM()
{
ctnt=document.getElementById('bigyusz').childNodes[0].nodeValue;
if (ctnt!='bigyusz') alert("You modified the page... Sorry you are
banned.");
}
setTimeout(function(){checkDOM();},1000);
</script>
</head>
<body>
<p id="bigyusz">bigyusz</p>
</body>
</html>
And the script:
// ==UserScript==
// @name test
// @namespace gmsucker
// @description test
// @include file:///home/calmarius/Development/www/gmsucker.htm
// ==/UserScript==
document.getElementById('bigyusz').innerHTML='másik bigyusz!';
----
I tested it and if you modify the dom the page detects it.
To resolve you can use unsafeWindow.checkDOM=function() {}
But afaik adding or removing functions to the unsafeWindow still
detectable (it fires some king of event)
You should also note that site authors can be tricky and they don't
put the checker script on every load or they may use a random name for
the function that checks.
Any ideas to completely hide the script?
(especially the authors of browsergames).
Scripts can be detectable if a scheduled js function check the dom and
the window object for modifications.
I've written a simple demo for this:
The page:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd">
<html>
<head>
<title>GM sucker page!</title>
<script>
function checkDOM()
{
ctnt=document.getElementById('bigyusz').childNodes[0].nodeValue;
if (ctnt!='bigyusz') alert("You modified the page... Sorry you are
banned.");
}
setTimeout(function(){checkDOM();},1000);
</script>
</head>
<body>
<p id="bigyusz">bigyusz</p>
</body>
</html>
And the script:
// ==UserScript==
// @name test
// @namespace gmsucker
// @description test
// @include file:///home/calmarius/Development/www/gmsucker.htm
// ==/UserScript==
document.getElementById('bigyusz').innerHTML='másik bigyusz!';
----
I tested it and if you modify the dom the page detects it.
To resolve you can use unsafeWindow.checkDOM=function() {}
But afaik adding or removing functions to the unsafeWindow still
detectable (it fires some king of event)
You should also note that site authors can be tricky and they don't
put the checker script on every load or they may use a random name for
the function that checks.
Any ideas to completely hide the script?
Anthony Lieuallen
Aug 25, 2009, 1:45:35 PM8/25/09
to greasemon...@googlegroups.com
On 08/25/09 05:46, Calmarius wrote:
> But afaik adding or removing functions to the unsafeWindow still
> detectable (it fires some king of event)
> But afaik adding or removing functions to the unsafeWindow still
> detectable (it fires some king of event)
If you alter the page, at all, in any way, and the author of that page
wants to detect that you're doing it (with javascript) you can't stop
him from doing so. The only thing you can do is GM_registerMenuCommand.
This in fact would be undetectable. But if the user clicks the menu,
and that changes something in the page, back to square one.
No matter what you can imagine doing to sneak past their detections,
they can add a detector for that, so you add a new sneaky method, so
they add a new detector ..
The winner is only the party more dedicated to updating changes, and
then only temporarily.
metzgerite
Aug 26, 2009, 8:46:04 PM8/26/09
to greasemonkey-users
In a battle of site hoster and script user, the script user has the
upper hand.
To start with, any method of detecting DOM changes needs to be able to
report these changes back to the server in order for the server to be
aware of it. Blocking reporting back by intercepting any HTTP
requests means you win.
You also have access to any scripts on the page while the page does
not have access to any userscripting. In the case of your simple
script above I could simply remove all setTimeout and setInterval page
functions, regardless of what they are named (you can access them by
index).
Basically in any escalating war the effort requires scales
dramatically for the website developer, and will quickly start
breaking the website for normal users who happen to have adblock
software, or noscript software, or have images turned off because they
are on a slow connection, or any other number of 'ors' that would
cause them to lose traffic. In the end the only way to make your
website 'userscript proof' is not to publish it in the first place.
upper hand.
To start with, any method of detecting DOM changes needs to be able to
report these changes back to the server in order for the server to be
aware of it. Blocking reporting back by intercepting any HTTP
requests means you win.
You also have access to any scripts on the page while the page does
not have access to any userscripting. In the case of your simple
script above I could simply remove all setTimeout and setInterval page
functions, regardless of what they are named (you can access them by
index).
Basically in any escalating war the effort requires scales
dramatically for the website developer, and will quickly start
breaking the website for normal users who happen to have adblock
software, or noscript software, or have images turned off because they
are on a slow connection, or any other number of 'ors' that would
cause them to lose traffic. In the end the only way to make your
website 'userscript proof' is not to publish it in the first place.
RodMcguire
Aug 27, 2009, 4:13:08 PM8/27/09
to greasemonkey-users
Some greasemonkey scripts really don't need to alter the DOM but they
do in order to put up a display or command panel. One might be able to
avoid this by creating it in a separate window (I haven't tried this)
but it is nice to have the panel attached to the page it applies to.
One could envision modifying greasemonkey somehow so that it allows a
separate chrome panel (that is undetectable by the target page) that
say contains a button labeled "repeatedly smite until dead". As long
as the action associated with this button just reads the target page
and emulates clicks its presence would be undetectable other than by
traffic analysis.
do in order to put up a display or command panel. One might be able to
avoid this by creating it in a separate window (I haven't tried this)
but it is nice to have the panel attached to the page it applies to.
One could envision modifying greasemonkey somehow so that it allows a
separate chrome panel (that is undetectable by the target page) that
say contains a button labeled "repeatedly smite until dead". As long
as the action associated with this button just reads the target page
and emulates clicks its presence would be undetectable other than by
traffic analysis.
Gordon Pettey
Aug 27, 2009, 7:45:57 PM8/27/09
to greasemon...@googlegroups.com
If you need that kind of functionality, you need your own add-on, not
Greasemonkey.
Greasemonkey.
RodMcguire
Aug 27, 2009, 8:37:41 PM8/27/09
to greasemonkey-users
On Aug 27, 7:45 pm, Gordon Pettey <petteyg...@gmail.com> wrote:
> If you need that kind of functionality, you need your own add-on, not
> Greasemonkey.
It is philosophically consistent with greasemonkey though it probably
> If you need that kind of functionality, you need your own add-on, not
> Greasemonkey.
won't be added unless it is written by somebody that really wants it.
For example, there are numerous current websites that use all sorts of
tricks to prevent viewers from copying text or pictures from them. For
example articles at http://snopes.com/ prevent you from highlighting
and copying text. Such restrictions can be gotten around with a user
script. Lets say I write a script for snopes and it puts a banner at
the top of the page that says something like "Snopes Copy Protection
Defeated". Snopes could easily detect that but not if the banner was
in a chrome separate panel. This issue becomes more important if
script writers start using general libraries that provide automatic
user interaction.
But for now I've only heard of game sites that try to defeat
userscripts so there is little call for this approach except from that
area. However if say the New York Times or AP tried to prevent people
from copying text and used anti-script software, then there might be
more of a call for such abilities.
Reply all
Reply to author
Forward
0 new messages