[..]
> Thank you for your response. I have learned something new and
> useful from it.
>> Allow me to explain, please --
> I posted the question because I want to satisfy my curiosity
> as well as to add another bit of information to my rather
> inadequate store of knowledge, but not to take up the
> challenge posed by the owner of that site (who, incidentally,
> threw a challenge to identify the Flash movie hidden inside
> another Flash movie, not to decypher the "hidden" codes of that page).
I've come late to this thread, but in case it's of any use I have a
couple of observations. If you want to disable the context menu,
oncontextmenu='return false;' in the body tag should do the trick.
onselectstart='return false;' and ondragstart='return false;' will
prevent users from being able to select items on the page to copy and
paste elsewhere. These event handlers are less than interesting in the
context of hiding code from curious users as not only are they not
universally supported, but turning javascript off will also disable them
where they are supported. An interesting application for these event
handlers is producing context sensitive menu systems using IE6 (for
example) as a vehicle for a thin client application. This has nothing to
do with hiding source code, it just makes for a flexible front end for a
web application, but should certainly not be treated as a totally robust
solution.
> As already mentioned, I am aware that source codes, no matter
> how they are camouflaged or cyphered, can be unmasked or
> decyphered. But here we would mean by "advanced users" such
> as yourself. I don't think I am wrong if I say that most
> surfers do not fall into this category.
Most surfers won't even attempt to look at source code. The problem that
you have if you wish to hide source code is that the only people that
you are hiding it from are the people that aren't looking for it. It's
sort of like placing a plaque of ROT13 encrypted braille twelve feet
above the street. Anyone that puts the effort into finding your code
will be able to read it. Encryption won't work, because it requires the
collaboration of the user to install a third party product to decrypt.
Obfuscation is what you are left with, and this will fail miserably with
anyone who really wants to find out what you have written. It may even
have the opposite effect of what you are trying to achieve, insomuch as
if you are making an effort to hide what you are doing, the curiosity of
the user may be engaged where it would not be normally. The harder it is
to crack, the more effort they will put in to crack it. You don't have
to be a hardcore *nix-head to be a hacker; it's more of a mentality.
> As already mentioned, too, I recently also saw a page on
> Adobe's site where the content shown by "view source" was
> practically bare. A little while later, when I returned to
> the same URL to take another look at it in order to try to
> determine how it was done, the page was back to "normal"; so
> I lost the chance to do my investigation work.
I suspect there was a degree of user error here, or maybe a lack of
undersanding of what was there. If there was a line of html, then a line
of content would have been displayed. I suppose you could have something
like the following:
<script src='/foo.js'></script>
<script>document.write(bar)</script>
But, in order to figure out what is going on all you have to do is type
http://foobar.com/foo.js (or whatever) into the address bar, download
the file and open it in a text editor. From there you just work
backwards to find out what the string value of 'bar' is delivered to the
browser for rendering. You could even employ a site ripper to download
all .js files on the site. I used to use Black Widow with a degree of
success, but I don't know if it's still around.
> I am curious to know the technique(s) involved, and I would
> be very grateful if you or someone else could either tell me
> or point me to a thread on here or resources elsewhere that I
> can read.
The question you really have to ask yourself is, is it worth the effort?
What are your goals in protecting your code? Is it *really* so
groundbreaking that people would want to steal it when there so many
royalty free scripts out there? If so, then I suspect that writing a
Flash movie/ActiveX Control/Java Applet would possibly be a better bet.
I don't think anyone actually tries to hide their code any more, and
you'll probably find that if someone like Adobe has what looks like
encrypted, obfuscated or otherwise hidden code it is probably a
byproduct of a dynamic, algorithmically(sp?) driven site rather than a
conscious effort to hide anything.
I guess theoretically you could have some java applet or activeX control
that is compiled on the server on an HTTP request via a custom COM
object or EXE file. It would be compiled each time with a unique key
which is also used to encrypt the html. The html page along with
associated javascript and ActiveX/Java applet comes back down the pipe.
The javascript interrogates the custom object, which delivers the key to
decrypt the encrypted HTML to be spat out via document.write(), after
which the custom object destroys or randomly changes the key. You'd have
to somehow prevent older browsers from seeing the page, and of course
with the use of a debugger this would be rendered useless. The above is
utter tosh in the real world of course, but I included it in case you
are looking for a seed for a discussion with your colleague.
FWIW, HTH, YMMV, HAND
Regards
Chris Marsh