Shadow coder ultimate stealth for your webpage!

General Topics
1

Hi malware fighters,

You find it inline, and well here: http://fantomaster.com/fantomasSuite/shadowCoder/fascodersv-e.cgi

enjoy,

polonus

2

Thanks for the link, however I’ m not sure of how this protects the web page ???

Al968

3

Hi al968,

No the code is not very intricate, and as long as the browser can handle it and understand it, protection like NoScript in the Mozilla-browser is the same as with the straight code. The only protection for your webpage is that others find it a bit harder to analyze your code and that is what it is used for mainly obfuscation to give added security,

polonus

4

This seems to be the opposite of what we’re trying to accomplish regarding Internet security. Why on earth would I want to view a web page which is trying so hard to hide from me what it’s doing? It makes you look like one of the bad guys.

5

Hi Alan Baxter,

You very well know that polonus is fighting evil wherever he goes, but the matter is protection of the webmaster code against malicious analysis. It is something very simple, see what Giorgio Maone posting, where I raised the same question tio see what it meant for NoScript to handle this.
If we do not discuss these matters, the malcreants will always be a step ahead of us, and I never ever believed in security through obscurity. I know hard script filters could find a way to block this kind of obfuscation, but that is by mistake for it is completely benign, but it always is with code as with a hammer you can sculpt with it, and ruin,

polonus

6

Huh? It provides no protection against malicious analysis by the bad guys. It merely prevents us good guys from attempting to verify your code isn’t malicious. If you’ve never believed in security through obscurity, then why are you suggesting this? I can probably dig it out myself if it’s on hackademix or the noscript forum, but it would be easier if you could provide a link to where Giorgio says how this tool could be useful.

7

Hi Alan Baxter,

@first point
Giorgio didn’t say it was useful in any way, I just asked him if with NoScript the protection was the same for the normal code as with this “shadow code”. I wanted to make sure we were always protected around by NoScript, that is good isn’t it, black hats never ask but abuse code, white hats have another attitude and the security aware work as I do in educating the user to be protected against the things he is not familiar with.
@ second point
This is not an code obfuscator, it is to protect webpage builders for code-napping, your browser-safe uni-encoded page code protector, see http://fantomaster.com/faprogs0.html#shadowcoder
It does not matter for the workings of NoScript, NoScript as effectively protects against bad code normally html-encoded or against this uni-encoded variety.
People for whom SEO is important may not want their code shared by everyone, if you opose that and are a proponent of open source also in this sense, I say OK you have a point there. Also if protection is specific it can be a problem, if the in-browser protection is on a general basis like NoScript protects, I see no problem.
@ third point
When people start to use it as they find it, and we did not discuss these issues here how could we be aware/protected as there was a malicious side-effect of uni-encoded pages, gonna dive into that with weak CGI scripts, but I doubt it can be helpful, only for cloaking purposes, but same goes with the use of an URL obfuscating calculator: hxxp://0x57E65A9E equals 87.230.90.158
So 87.230.90.158/cgi/scripts/tools/newdsn.exe would still read hxxp://0x57E65A9E/cgi/scripts/tools/newdsn.exe, but the browser will translate the code as hxxp://0x57E65A9E/cgi/scripts/tools/newdsn.exe If with NoScript scripts is not allowed there is no danger, on the other hand a webmaster that does not want his tools being compromised could use the above obfuscation to be better protected, but there are alsways two sides of the matter here, that is why we discuss it here, I could also have packed the above somewhat like this:

 eval(function(p,a,c,k,e,r){e=String;if(!''.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('',2,0,''.split('|'),0,{}))

Well the online packer is to be found here: http://dean.edwards.name/packer/

polonus

8

Of course. I thought that’s what we are doing. I don’t understand why you keep repeating this. If I didn’t want a dialog or response, I wouldn’t have posted in this topic, especially with questions. I don’t have a problem with you posting. I just disagree with your assessment that this is a white-hat tool.

I’ll try to restate my point in a different way. This looks like a tool which compromises security, not enhances it. I think the bad guys would love to use tools like this and some of the others provided on its web site. Do you ever use the View Page Source feature of your browser? If it ever showed me an obfuscated page like the output form the tool you linked, I’d block its domain from entering my browser.

NoScript isn’t the full solution to security. Obfuscation can hide other nasty tricks from an inquisitive end user that wants to view the page source at times like you and I do. You mention “security aware work as I do in educating the user to be protected against the things he is not familiar with”. Good work, usually, but this seems like a tool which makes it harder for the educated user to protect herself.

You say “it is to protect webpage builders for code-napping”. Automated tools can easily extract its content. This is faux protection.

9

Hi Alan Baxter,

Well this putting the issue in the right perspectives, and I agree fully with you that we have to get at the bottom of this and hope that others also report what they think of obfuscation or scrambling of code.
Also agree with you that protecting the code of the coder in such a way can be a pretext for a malcreant or to use it for evil purposes. There is an awful lot of these JS obfuscators online. When you use it with a packer that turns out something that cannot be reconstructed by the user that runs it in his browser and the code is being compressed as well. It is even possible to scramble a scrambled code and check it online that it does not throw up errors and just run in the browser.
In the virus and worms we had a webmaster that was supportive of an obfuscated IFrame redirect, and could not understand why avast flagged that, because the redirect was meant to be there.
So my basic line is obfuscating to be avoided as a protection of propriety-code nor is it a protection method for the code from being hacked and changed, so should we frown upon it whenever we find it on a web-page and therefore block it or what is your opinion, my friend. I am curious for your views upon the matters at hand?
Now just another example where you can test the scrambled code to do what it was supposed to:
http://www.tero.co.uk/scripts/scrambler.php

polonus

10

Hi, polonus. Thanks for hanging in there with me. I hate feeling like I’m arguing with you.

This reminds me of NoScript’s blocking XSS or clickjacking. NoScript has to block all everything that might be dangerous because it’s too difficult to reliably and efficiently verify what is going on by just examining the code or even running it… JavaScript is Turing complete, so it’s not easy, and often not possible, to verify that anything but the most simple piece of code is benign. Your webmaster needs to be less suspicious-looking.

So my basic line is obfuscating to be avoided as a protection of propriety-code nor is it a protection method for the code from being hacked and changed, so should we frown upon it whenever we find it on a web-page and therefore block it or what is your opinion, my friend. I am curious for your views upon the matters at hand?

Well, at least I’d be suspicious. Frankly, I don’t examine the source of most of the web pages and external scripts that run in my browser, so I might be executing obfuscated and/or packed instructions without knowing it. I reduce my attack surface by practicing safe hex with default deny, i.e. allow no dangerous privileges to a site by default. On sites I trust, allow only those privileges that are necessary. The only heavy-duty security tool I routinely use to implement this philosophy is Firefox with NoScript. I’m not quite as careful as you, polonus.

Now just another example where you can test the scrambled code to do what it was supposed to: http://www.tero.co.uk/scripts/scrambler.php

Problem is, you can’t always tell what non-trivial code will do just by running it. Turing completeness and the halting problem come to mind here.

Edit: Love your shoes!