Decoding html pages

**Gregor Kofler** · Oct 25 '08, 08:55 PM

Re: Decoding html pages

Santander meinte:

So it possible to delete javascript code from page after script has been
executed?

Yes. "Jorge" started a thread in this NG 7 days ago.

That's very intersting, so it possible hide code all the same.

No. Not if somebody is determined to get the code. Hasn't this become
clear, yet?

Gregor

**David Mark** · Oct 26 '08, 08:55 PM

Re: Decoding html pages

On Oct 24, 11:59 pm, Spamless <Spaml...@Nil.n ilwrote:

On 2008-10-25, Conrad Lender <crlen...@yahoo .comwrote:
>

On 2008-10-25 02:37, Spamless wrote:

How well does it work? Have you seen (I have) javascript which
deletes itself from the page (or other Javascript)? It runs some code
then looks for script elements and ... uses the DOM to remove them.
I've seen that a time or two in exploit scripts (whose authors really
don't want you to see what is going on). Will firebug show the code
which was on the page?

>

Yes.
http://groups.google.com/group/comp....5f059ad2b00e20

>
I think no.

You don't have to think as several posters have told you why you are
wrong.

>
It leaves a reference but does not show the code.

Meaningless.

>
With an HTML page,
>
<html><head></head><body onload="goaway( )">
<script src=go.js></script>
All gone!
</body></html>
>
and a javascript file, go.js
>
function goaway() {
alert("Be GONE!");
>
}
>
loading the page and then running firebug to examine it shows the
source and even the code from the loaded Javascript file
(there is a "+" sign next to the
<body onload="goaway( )">
section which can be used to expand it and find the
the <script src=go.js></scriptinclusion which can
be expanded to show the source creating the alert box).

And?

>
Changing go.js to
>
function goaway() {
alert("Be GONE!");
togo=document.b ody.childNodes[1];
document.body.r emoveChild(togo );
>
}
>
and reloading the page removes
<script src=go.js></script>
from the DOM (as one can see by using the DOM tool
(TOOLS|DOM_INSP ECTOR).

You don't even have a glimpse of a clue here. Go back and re-read the
previous posts in this thread (excluding the ones you wrote.)

[snip]

**Spamless** · Oct 26 '08, 11:45 PM

Re: Decoding html pages

On 2008-10-26, David Mark <dmark.cinsoft@ gmail.comwrote:

>>
>and reloading the page removes
>=A0 <script src=3Dgo.js></script>
>from the DOM (as one can see by using the DOM tool
>(TOOLS|DOM_INS PECTOR).

>
You don't even have a glimpse of a clue here. Go back and re-read the
previous posts in this thread (excluding the ones you wrote.)

I don't have a glimpse of a clue there? It is not removed?
Oh, but it is removed from the HTML. The use of local variables
wrapped in an anonyous function and the removal of the material from
the HTML page removes all references from firebug's DOM panel.
Those are details of which I am sure you are aware (or should be).
But of course that is nonsense and I am clueless. They could not
be removed, for you say so.

However, I did err due to an apparent difference in the handling
of local vs. remote files in firebug's SCRIPTS panel. By the way,
in rereading all the prior messages I have seen no one comment
on this. Alas.

With an HTML page,

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

loading

[go.js]
-------
function goaway() {
alert("Be GONE!");
var togo=document.b ody.childNodes[1];
document.body.r emoveChild(togo );
document.body.r emoveAttribute( "onload");
goaway=null;
onload=null;
}

The HTML panel of firebug surely shows the script gone.
The DOM tool shows the global Javascript functions
onload and goaway, but they are null and not clickable.

I am sure you are aware of this having tested it so
thoroughly.

The SCRIPT panel of firebug shows the page source and
has a drop down list allowing one to see the contents
of go.js. Before using that, I changed (on my local
copy) "Be GONE!" to "Be GENE!" and used it. The script
panel, in showing go.js apparently loaded it again directly
(it showed "Be GENE!") (and of course, that is what the code
at google is designed to foil - another separate load of
the script file). Of course, that google posted code cannot
work - for you said so. After all it only requires, as you
said, but ONE connection to the web server to get the
material, not one to set the accessibility and another to
get the script file (and then access is blocked).

I am sure you are aware of all this having tested it so
thoroughly.

HOWEVER, putting the files on a REMOTE server and using
the SCRIPT panel (and its drop down list) shows the go.js
file, but running a packet capture shows that it did NOT
reload the file (and did not send a query to see if it
had changed). I short, the SCRIPT tab apparently shows
the javascript as obtained in its first download.

By the way, what packet capture programme did you run when
you tested this?

Since you surely were aware of the differences in handling
local and remote files and the fact that, for example,
using anonymous global functions (with no name to be used)
wrapping all local variables and removing the material from
the HTML of the page would definitely remove all references
to all the Javascript both from the HTML panel and the DOM
panel but would leave access to the material in the SCRIPTS
panel which treats local and remote files differently, it
appears.

Surely you did check before saying "NONSENSE" and "CLUELESS"
but I wish you had given some details about your results
instead of simply saying "NONSENSE" and "CLUELESS" sufficiently
many times to make them true.

What *were* the results of your tests and what code did you use?

**Spamless** · Oct 27 '08, 12:15 AM

Re: Decoding html pages

On 2008-10-26, Spamless <Spamless@Nil.n ilwrote:

The SCRIPT panel of firebug shows the page source and
has a drop down list allowing one to see the contents
of go.js. Before using that, I changed (on my local
copy) "Be GONE!" to "Be GENE!" and used it. The script
panel, in showing go.js apparently loaded it again directly
(it showed "Be GENE!")

HOWEVER, putting the files on a REMOTE server and using
the SCRIPT panel (and its drop down list) shows the go.js
file, but running a packet capture shows that it did NOT
reload the file (and did not send a query to see if it
had changed). I short, the SCRIPT tab apparently shows
the javascript as obtained in its first download.

Let me check your expertise. The above is true. Why?
And have you tested your explanation?

**Spamless** · Oct 27 '08, 01:25 AM

Re: Decoding html pages

Rats. Firebug makes it easy to search the cache for the original
download of the script.

On 2008-10-26, Spamless <Spamless@Nil.n ilwrote:

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.
>
*: 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. ...

....

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.

But firebug makes it easy to find the file in cache.

All the above is true, since I used "apparently ."

For remote files, firebug does not go get it again.

Why the difference between my first test (when it first tested
it I was using local files) and for remote files?

Firefox does not cache loads of local files. Why should it? The files
are right there, easily loaded again.

The SCRIPTs panel in firebug has a drop down list of files loaded
for the current page. It is a search tool to locate the data in
firefox's cache. For local files, not saved in cache, firebug had
to reload the local file. For remote files, it finds them in the
browser's cache and loads from there (so you see original downloaded
versions). Loaded from cache and not from the browser's memory?
Loading a file from a remote server, checking the access time of the
copy in firefox's cache, waiting a minute or so and then using the
SCRIPT's panel's drop down list to show the contents of go.js and
checking the access time again of the cached copy showed that it had
just been read/accessed.).

So, the above is true (you can remove and block references in firebug's
HTML and DOM panels by removing the javascript node and using local
variables wrapped in an anonymous function) but you have the copies
in the brower's cache. Firebug has a cache access tool to find and
display those cached copies and makes them easily accessible (both
the original HTML page and javascript code it loaded).

**Conrad Lender** · Oct 27 '08, 02:35 AM

Re: Decoding html pages

On 2008-10-27 02:20, Spamless wrote:

Rats. Firebug makes it easy to search the cache for the original
download of the script.

Why are you still trying to make this work? You're trying to trick the
GUI of an add-on in one particular browser. And you *know* that anybody
with a rudimentary understanding of the web can just pick the file
contents from the HTTP stream (you mentioned packet sniffers yourself).

Some things just can't be done. There's no shame in admitting defeat
against the impossible. I've only ever found _one_ reliable way to keep
people from copying scripts: write crappy scripts :-)

- Conrad

**Lasse Reichstein Nielsen** · Oct 27 '08, 05:45 AM

Re: Decoding html pages

Conrad Lender <crlender@yahoo .comwrites:

I've only ever found _one_ reliable way to keep
people from copying scripts: write crappy scripts :-)

Looking at the web today, I'd say that strategy is doomed to fail too :)
/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

**Gregor Kofler** · Oct 27 '08, 08:25 AM

Re: Decoding html pages

Conrad Lender meinte:

Some things just can't be done. There's no shame in admitting defeat
against the impossible. I've only ever found _one_ reliable way to keep
people from copying scripts: write crappy scripts :-)

Doesn't work, too. In fact, the crappier the script, the more it will
spread...

Gregor

**Spamless** · Oct 27 '08, 08:45 AM

Re: Decoding html pages

On 2008-10-27, Conrad Lender <crlender@yahoo .comwrote:

On 2008-10-27 02:20, Spamless wrote:

>Rats. Firebug makes it easy to search the cache for the original
>download of the script.

>
Why are you still trying to make this work? You're trying to trick the
GUI of an add-on in one particular browser. And you *know* that anybody
with a rudimentary understanding of the web can just pick the file
contents from the HTTP stream (you mentioned packet sniffers yourself).

I wanted to know just how far one could push fooling firebug (since
others seem to rely heavily on it) and *if* it could be fooled
completely and if not, what to watch out for - which tools *can*
be fooled and which can't, and why.

Some things just can't be done.

But why can't it be done. I am a mathematician and need proofs.

There's no shame in admitting defeat against the impossible. I've only
ever found _one_ reliable way to keep people from copying scripts: write
crappy scripts :-)

It is a trick. It makes it difficult for the unwary even to realize that
something has happened (that there *was* code on a page when the "live"
panels in firebug, HTML and DOM, no longer show it - if you forget to
check the cache via the SCRIPT panel you may miss something).

It's just a trick. You and I can get around it. I just want to know
enough of what can be done so that, if I come across it (and I have
come across exploit pages which remove Javascript) I will recognize
it and not be fooled. Don't rely on the HTML and DOM view in firebug
which are live and be fooled by removing data from a page (and avoiding
leaving global Javascript variables and non-anonymous functions around
which the DOM view can show).

Until I was sure how the SCRIPT panel in firebug works (it seems
to be a cache access tool - and the file WILL BE in cache) I didn't
*know* for a fact whether or not firebug could be completely fooled.
As data is in the cache, and firebug has a tool to search and
access that, that tool cannot be fooled. The live tools can.

By the way, did you realize that SCRIPT seems to be a cache access
tool and why about:cache in firefox and clicking on an item there
may not show the cached data? It sends a request to the original
source only asking for a more recent value (an "If-Modified-Since:"
header). It may return newer, not cached data. That may not be a
reliable way to check cached data (onless one is offline to force
a cached value to be used?).

A litle detail - but I like to know how things work in depth.

Ah, heck ... this is a Javascript forum. The original question was
just about deobfuscating some (simply) obfuscated code. That led
to a reference to a google page and the poster did not know how
the Javascript there worked - but it was a PHP blocker. That led
to the question of how to find things on a page. That led to using
firebug. That led to questions as to what it shows and can one
fool (at least parts of) it.

**Gregor Kofler** · Oct 27 '08, 09:05 AM

Re: Decoding html pages

Spamless meinte:

>Some things just can't be done.

>
But why can't it be done. I am a mathematician and need proofs.

You're a mathematician? Then you know what an axiom is.

Gregor

**Conrad Lender** · Oct 27 '08, 10:25 AM

Re: Decoding html pages

On 2008-10-27 09:41, Spamless wrote:

>Some things just can't be done.

>
But why can't it be done. I am a mathematician and need proofs.

I'm not a mathematician. I can't even read moderately complex
mathematical proofs (I've tried, but the notation alone is enough to fry
my brain), so I'll settle for common sense:

In the end, the scripting engine has to see the raw source code.
Whatever you do, there must be a way for a HTTP user agent to read (and,
if necessary, decode) your secret message (ie, the hidden script). What
a UA can do, an attacker can do as well. It may be *complicated*, but
the UA itself is proof that it *can* be done.

>There's no shame in admitting defeat against the impossible. I've only
>ever found _one_ reliable way to keep people from copying scripts: write
>crappy scripts :-)

....

It's just a trick. You and I can get around it. I just want to know
enough of what can be done so that, if I come across it (and I have
come across exploit pages which remove Javascript) I will recognize
it and not be fooled.

From that point of view, it's indeed an interesting question. I've been
working with a network security person from time to time, and from what
I hear, JS exploits have become a lot more common and more sophisticated
over the last years. Since the Web 2.0 thing took off, people are also
less likely to disable scripting than before.

I consider it part of my job to be able to spot what's going on, and
your tests with Firebug were actually quite interesting (_and_ on topic
here, as far as I'm concerned). It just seemed to me that you were
approaching this from the opposite side ("Rats, I couldn't fool Firebug"
instead of "Hehe, they couldn't fool Firebug").

By the way, did you realize that SCRIPT seems to be a cache access
tool and why about:cache in firefox and clicking on an item there
may not show the cached data? It sends a request to the original
source only asking for a more recent value (an "If-Modified-Since:"
header). It may return newer, not cached data.

Same thing happens with "view source". It will (sometimes) send a new
request, but *without* the cookies, and instead of the source of the
page you're interested in, you'll see the source of the login form :-/
Firebug is one way to work around that.

- Conrad

**Spamless** · Oct 27 '08, 05:55 PM

Re: Decoding html pages

On 2008-10-27, Conrad Lender <crlender@yahoo .comwrote:

On 2008-10-27 09:41, Spamless wrote:

>By the way, did you realize that SCRIPT seems to be a cache access
>tool and why about:cache in firefox and clicking on an item there
>may not show the cached data? It sends a request to the original
>source only asking for a more recent value (an "If-Modified-Since:"
>header). It may return newer, not cached data.

Checking at mozilla/firefox all the information on browsing the cache
seems to be "use about:cache" (no mention of forcing it NOT to load
material with Work Offline).

Same thing happens with "view source". It will (sometimes) send a new
request, but *without* the cookies, and instead of the source of the
page you're interested in, you'll see the source of the login form :-/
Firebug is one way to work around that.

Or, in firefox, FILE|WORK_OFFLI NE?

(and I remember one spammer who put up a new site and did not set
*.php files to be run through the PHP engine - so accessing the
index.php file showed its source and inclusions of other *.php
files which showed ...)

**David Mark** · Oct 28 '08, 03:45 AM

Re: Decoding html pages

On Oct 26, 7:37 pm, Spamless <Spaml...@Nil.n ilwrote:

On 2008-10-26, David Mark <dmark.cins...@ gmail.comwrote:
>
>
>

and reloading the page removes
=A0 <script src=3Dgo.js></script>
from the DOM (as one can see by using the DOM tool
(TOOLS|DOM_INSP ECTOR).

>

You don't even have a glimpse of a clue here. Go back and re-read the
previous posts in this thread (excluding the ones you wrote.)

>
I don't have a glimpse of a clue there? It is not removed?

By "there" I mean any subject with even a remote connection to browser
scripting, debugging, browsers in general, Firefox specifically, etc.

Your misconceptions have been described repeatedly in this thread. Re-
read it from the start. Then realize that if you don't want people to
see your script, you shouldn't post it on a public Web server. End of
story.

Oh, but it is removed from the HTML. The use of local variables

Best of luck hiding your script. It must be really good to go to all
of this trouble.

Decoding html pages

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment