Re: Decoding html pages

I've read about this method also here:
http://www.javascriptkit.com/javatutors/loadjavascriptcss2.shtml

Their code example not working for me though. Since there is no way to make
javascript available for a browser and also keep it from getting to the
client machine, probably the way is just to make it a more difficult to see
for the casual users via obfuscating javascript.

also php method:
http://bytes.com/forum/thread749685.html

--------------------

"Spamless" <Spamless@xxxxxxx> wrote in message
news:49041313$0$28696$22fed638@xxxxxxxxxxxxxxxxx
On 2008-10-25, Santander <santander@xxxxxxxxx> wrote:
So it possible to delete javascript code from page after script has been
executed? That's very intersting, so it possible hide code all the same.
Could you show html page example that use this approach?

Santander

It is easy to "hide" it. One can even hide it very well from the majority
of
site visitors. You can obfuscate it. But ... it has to be sent to the
visitor's browser at least once if it is going to be useful and the
Javascript engine has to be able to de-obfuscate/decode it with the
material
provided. The visitor will have a copy and the tools to understand it but
... it can be hidden but not effectively from those with the skills and
interest to discover and understand it.


It is easy to remove it from the HTML page (the DOM function,
removeChild(.)
which can remove a node from a page). It is harder to hide it from firebug
which shows (in its DOM panel) user defined (Javascript) functions and
variables - contents still in the Javascript engine besides the HTML page.
It is not HTML but firebug can still show it. One cannot "undefine" things
in Javascript which uses its own garbage collector to remove items.

So, yes ... use the DOM model (as below) and you can remove it from the
page. It is a bit more of a challenge also to foil firebug's ability to
show
Javascript variables and functions.


Here is what I have come up with to hide it from firebug.

My first attempt:

A web page:
[a.html]
--------
<html><head></head><body onload="goaway()">
<script src=go.js></script>
All gone!
</body></html>

loading a script (go.js)
[go.js]
-------
function goaway() {
alert("Be GONE!");
togo=document.body.childNodes[1]; // <-- BAD GLOBAL VARIABLE!!
document.body.removeChild(togo);
}

which pops up an alert box. When you close the alert box, use the DOM tool
or firebug's HTML panel or other tools to see that there is no indication
of
how the alert box was created other than the reference to goaway() as the
onload function - it has been removed from the page. Easy.

That was my first attempt ...

HOWEVER ...

In firebug the HTML view (when the alert box is on screen) shows a "+"
indicating that one can expand a tree element and see the script. That
disappears when the element is removed (after you close the alert box).

The HTML panel in firebug is foiled. But ... it has other tools.


HOWEVER ...

In firebug, in the DOM view (the default is also to show user defined
functions and Javascript variables) of the document one finds a reference
to
go.js (why? because of "togo" - see below) and one can right click that
and
choose to inspect it in the HTML window to find it and see the code BUT
apparently[*] it goes and reloads it to display it (as it is gone from the
document). Part of this thread shows a PHP block which prevents one from
getting a script except when loading the page it is on. I found it strange
that firebug shows the reference to the script) when the [script src ...]
node has been removed until I realized that what it was showing was the
"togo" variable which was used. It shows that reference but seems to need
a
reload to display the script.

*: After loading the page, I renamed go.js and then tried to use firebug
to
show it in the HTML panel and this time it failed. So it seems that
firebug can partly automate sending a new, separate request for the
script which is gone from the page and access to which can be blocked
except when the page is loaded (or once per day, or once from each IP
address or whatever). I also tried changing go.js to simply say
alert("DUMMY") before opening the firebug window and THAT is what
using the DOM tool, choosing to view the go.js file in the html panel.
Again, the prior discussion in the thread showed a way to send
different
Javascript except when the page is loading so if that trick is being
used, using the DOM tool in firebug to view the included script code
may mislead one.


HERE IS A BETTER VERSION:

[go.js]
-------
function goaway() {
alert("Be GONE!");
var togo=document.body.childNodes[1];
document.body.removeChild(togo);
}

See the difference? "var". A local variable!

Why better? FIREBUG, in its DOM view shows information about the page. the
togo variable was defined as a global variable and remained in the
Javascript engine and forces the reference to the Javascript to remain.

In the second version with a local variable, the DOM tool shows NO
reference
to the go.js file. It is all apparently gone except if one enables the
SCRIPT panel (which forces a reload) for that shows the reference to go.js
(but not its contents).

All gone? No. The DOM's view (by default) shows user defined functions and
so we still have a reference to goaway and one can choose to show its code
in the HTML panel and THAT (apparently) does not require a reload of the
go.js file. One can remove the onload attribute

function goaway() {
alert("Be GONE!");
var togo=document.body.childNodes[1];
document.body.removeChild(togo);
document.body.removeAttribute("onload");
}

but goaway was still defined as a global variable (a function)
and still appears in the DOM panel of firebug. What to do?

function goaway() {
alert("Be GONE!");
var togo=document.body.childNodes[1];
document.body.removeChild(togo);
document.body.removeAttribute("onload");
goaway=null;
}

There is still a reference to goaway in the DOM view but ... it is null
(one could also use undefined).

HOWEVER, the onload(event) function has been (and is still) defined
but is no longer an attribute of the body. The DOM module shows the
onload() function defined but, again, getting it seems to require a
reload of the go.js file (which can be blocked).


So ... let's make the onload function reference useless.

[go.js]
-------
function goaway() {
alert("Be GONE!");
var togo=document.body.childNodes[1];
document.body.removeChild(togo);
document.body.removeAttribute("onload");
goaway=null;
onload=null;
}

There are (in firebug's DOM panel) still two appearances of functions
defined in Javascript, onload and goaway. Both, however are null.

Finally I think that may foil firebug but leave references to (now null)
functions.

So, you can remove the Javascript node from the HTML page (and HTML only
tools will show it gone) but global variables remain in the Javascript
object (until garbage collection removes them). Use local variables but
the
reference to a global function remains.


If you are willing to modify the DOM as the page is loading (which may
not work in all browsers and may not be a good idea) the following
may work.


I wanted to avoid trying to remove a node in the DOM while the page was
loading which is why I did not use an anonymous function.

On the other hand,

[a.html]
--------
<html><head></head><body>
<script src=go.js></script>
</body></html>

[go.js]
-------
(function () {
document.write("Go away.");
alert("Be GONE!");
var togo=document.body.childNodes[1];
document.body.removeChild(togo);
document.body.removeAttribute("onload");}) ()

does work in firefox 2.0.0.16 in Linux and there are no global variables
(even functions) defined to be presented in firebug's DOM panel. The
function used is used anonymously.


BUT in firefox, using VIEW|PAGE_SOURCE shows the original source code with
the [script src=go.js][/script]. I don't think one will be able to get rid
of that and again, earlier messages showed a server side way to block
access
to such a file except when loading a particular page. One can also block
it
more permanently, blocking all but one load from every IP address, for
example. You may also see the reference to go.js in firebug's SCRIPT
panel.

Of course, if you see the source code and the load of go.js, it is in your
browser's cache and can still be found.


(By the way, I tried setting onload="..." to run an anonymous function
which
used XMLHttpRequest to get code from a file and then eval that result
without defining any functions or non-local variables of my own - but that
defined the "onload" function which firebug showed in the DOM panel -
again,
that showed the location of the source file from which I loaded the code,
but not the code itself - and that is apparently going to be available via
Firefox's VIEW_SOURCE tool.)

.

Relevant Pages

  • Re: Decoding html pages
    ... It is easy to remove it from the HTML page (the DOM function, ... It is not HTML but firebug can still show it. ... functions and Javascript variables) of the document one finds a reference to ...
    (comp.lang.javascript)
  • Re: inheritance question
    ... b is a reference to JavaScript object. ... That's a very common mistake so don't be ashame. ... JavaScript context has nothing in common with DOM tree - but it is able ...
    (comp.lang.javascript)
  • Re: Javascript support in RISC OS browsers
    ... There is no such thing as a simple JavaScript implementation either :-) Lack ... various RISC OS browsers? ... aside, Mozilla/Firefox again provides the reference version, but the ... integration with a DOM implementation? ...
    (comp.sys.acorn.programmer)
  • Re: FAQ Update 9.85 Dated 2007-08-31
    ... browsers and the DOM are not motivated to by and read ... reference works on the subject (and the book's authors are ... not motivated to pay such individuals to do reviews of ... JavaScript: TDG was reviewed by Douglas Crockford, ...
    (comp.lang.javascript)
  • Re: FAQ Update 9.85 Dated 2007-08-31
    ... who are already familiar with javascript, web browsers and the DOM are ... not motivated to by and read reference works on the subject (and the ... book's authors are not motivated to pay such individuals to do reviews ... JavaScript: TDG was reviewed by Douglas Crockford, ...
    (comp.lang.javascript)
Loading