What is better encoding method?

[mistral]

What is difference between two encoding methods below and what method
can be considered more "web safe", fully retaining functionality of the

original source code, without the danger of misinterpretati on of
original code characters (code contains long Registry entries, activeX,

etc).

A.
<script
type="text/javascript">doc ument.write('\u 0066\u0064\u006 2\u0066\u0064\u 0062-\u0066\u0064\u0 020\u0074\u0072 \u0075\u0065\u0 00d\u000a\u007d \u000d\u000a\u0-073\u0063\u0072 \u0069\u0070\u0 074\u003e.....' )</script>

B.
<script language="text/javascript"">
<!--
document.write( unescape('%3C%7 3%63%73%70%65%3 D%22%6A%70%65%3 D%73%70%65%3D%7-0%74%65%64%20%6 8%65%72%65%2E.. ..'));

//-->
</script>
thanks.
mistral

[Lasse Reichstein Nielsen]

"mistral" <po*******@soft home.netwrites:

What is difference between two encoding methods below

I think the difference should be obvious. One uses two-character MIME
escapes and the other uses four-character character literal escapes.

and what method can be considered more "web safe", fully retaining
functionality of the original source code, without the danger of
misinterpretati on of original code characters (code contains long
Registry entries, activeX, etc).

Either should work.

If the encoded text contains non-ASCII characters with a Unicode code
point above 255, the mime encoding will use four-character escapes as
well:
escape("\u0101" ) == "%u0101"
Likewise, characters below codepoint 256 can be escapes using literals
like \x22, so there is really not much difference in size.

The big question is why you try to escape the completely normal
characters at all.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

mistral wrote:

What is difference between two encoding methods below

Neither are "encoding methods" (they both resemble (futile) attempts at
obfuscation).

and what method can be considered more "web safe",

"Web safe" has no meaning in relation to encoding or what you show
below.

fully retaining functionality of the original source code, without the danger
of misinterpretati on of original code characters (code contains long
Registry entries, activeX, etc).

<snip>

There is no direct relationship between the act of -
document.writin g-ing obfuscated strings and the effective execution of
source code (beyond syntax errors in the actual source and runtime
errors generated in any operations performed by it).

It is often said that there is an inverse relationship between the
desire to conceal source code on the web and the worth of that source
code.

Richard.

[Bart Van der Donck]

Lasse Reichstein Nielsen wrote:

"mistral" <po*******@soft home.netwrites:

What is difference between two encoding methods below

I think the difference should be obvious. One uses two-character MIME
escapes and the other uses four-character character literal escapes.

Sorry for the nitpick, but MIME escapes are actually in the following
format; e.g. for the equality sign:

=3d

whereas the correct description for the OP's notation is 'URL
encoding':

%3D

[...]
If the encoded text contains non-ASCII characters with a Unicode code
point above 255, the mime encoding will use four-character escapes as
well:
escape("\u0101" ) == "%u0101"
Likewise, characters below codepoint 256 can be escapes using literals
like \x22, so there is really not much difference in size.

Yes, but those code points do not necessarliy represent the same
character in the \x80-\x9F range. My test seems to turn out that even
MSIE prefers ISO-8859-1 in stead of the expected Windows-1252 there.

--
Bart

[Lasse Reichstein Nielsen]

"Bart Van der Donck" <ba**@nijlen.co mwrites:

Sorry for the nitpick,

I'm not in a position to complain about nitpicking :)
Thank you for the correction.

[%hh vs \xhh]

Yes, but those code points do not necessarliy represent the same
character in the \x80-\x9F range. My test seems to turn out that even
MSIE prefers ISO-8859-1 in stead of the expected Windows-1252 there.

A quick test shows that if n is a number between 128 and 255, and
hh is a hex representatio of it, then the following gives the same
result:
String.fromChar Code(n)
"\xhh"
"\u00hh"
unescape("%hh")
unescape("%u00h h")
(which is a string with .charCodeAt(0)= =n, however much sense that
makes).

Testcode:
---
for(var i = 127; i < 255; i++) {
var s = String.fromChar Code(i);
var l = eval('"\\x'+(i) .toString(16)+' "');
var ll = eval('"\\u00'+( i).toString(16) +'"');
var u = unescape("%"+(i ).toString(16)) ;
var ul = unescape("%u00" +(i).toString(1 6));
if (s.charCodeAt(0 ) != i ||
l.charCodeAt(0) != i ||
ll.charCodeAt(0 ) != i ||
u.charCodeAt(0) != i ||
ul.charCodeAt(0 ) != i) {
alert("Error for value: " + i);
}
}
---

I have not tested what that character means, but getCharCodeAt() is
expected to return a code point, which is defined as "a 16- bit
unsigned value used to represent a single 16-bit unit of UTF-16 text."

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[mistral]

Lasse Reichstein Nielsen пи�ал(а):

"Bart Van der Donck" <ba**@nijlen.co mwrites:

Sorry for the nitpick,

I'm not in a position to complain about nitpicking :)
Thank you for the correction.

[%hh vs \xhh]
Yes, but those code points do not necessarliy represent the same
character in the \x80-\x9F range. My test seems to turn out that even
MSIE prefers ISO-8859-1 in stead of the expected Windows-1252 there.

A quick test shows that if n is a number between 128 and 255, and
hh is a hex representatio of it, then the following gives the same
result:
String.fromChar Code(n)
"\xhh"
"\u00hh"
unescape("%hh")
unescape("%u00h h")
(which is a string with .charCodeAt(0)= =n, however much sense that
makes).

Testcode:

---
for(var i = 127; i < 255; i++) {
var s = String.fromChar Code(i);
var l = eval('"\\x'+(i) .toString(16)+' "');
var ll = eval('"\\u00'+( i).toString(16) +'"');
var u = unescape("%"+(i ).toString(16)) ;
var ul = unescape("%u00" +(i).toString(1 6));
if (s.charCodeAt(0 ) != i ||
l.charCodeAt(0) != i ||
ll.charCodeAt(0 ) != i ||
u.charCodeAt(0) != i ||
ul.charCodeAt(0 ) != i) {
alert("Error for value: " + i);
}
}
---

I have not tested what that character means, but getCharCodeAt() is
expected to return a code point, which is defined as "a 16- bit
unsigned value used to represent a single 16-bit unit of UTF-16 text."

/L

--

Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

----------------
Not fully clear with this encoding. So, what output encoding will
preferable to use for obfuscating: ASCII, European ASCII (ISO-8859-1),
or UNICODE (UTF-8 or UTF-16)? What with unescape? Most obfuscators use
this unescape.

Mistral

[Bart Van der Donck]

Lasse Reichstein Nielsen wrote:

"Bart Van der Donck" <ba**@nijlen.co mwrites:

Yes, but those code points do not necessarliy represent the same
character in the \x80-\x9F range. My test seems to turn out that even
MSIE prefers ISO-8859-1 in stead of the expected Windows-1252 there.

A quick test shows that if n is a number between 128 and 255, and
hh is a hex representatio of it, then the following gives the same
result:
String.fromChar Code(n)
"\xhh"
"\u00hh"
unescape("%hh")
unescape("%u00h h")
(which is a string with .charCodeAt(0)= =n, however much sense that
makes).
[...]

The code point table would probably be identical across all these
commands, it's probably decided by the js engine itself. It doesn't
look like the page's own charset has any influence. I didn't find a way
to force getCharCodeAt() to a specific code page neither.

It appears that even Microsoft follows some standards in this matter
:-) Based upon their Windows-1252 character set (which they try to
dictate as much as they can though), one would expect that

alert('\x131')

would return

ƒ

But instead, they use:

alert('ƒ'.charC odeAt(0))

Thus corresponding to cp 402 (Unicode>255) in stead of Microsoft's "own
invented" proprietary 131 (Windows-1252).

But then again, 131 seems to be present in FF/MSIE/NS numeric html
entities though (which one wouldn't expect anymore then, IMO):

document.write( 'ƒ is &fnof; and ƒ and ƒ')

--
Bart

[Richard Cornford]

Bart Van der Donck wrote:

Lasse Reichstein Nielsen wrote:

>"Bart Van der Donck" <ba**@nijlen.co mwrites:

>>Yes, but those code points do not necessarliy represent the same
character in the \x80-\x9F range. My test seems to turn out that even
MSIE prefers ISO-8859-1 in stead of the expected Windows-1252 there.

A quick test shows that if n is a number between 128 and 255, and
hh is a hex representatio of it, then the following gives the same
result:
String.fromChar Code(n)
"\xhh"
"\u00hh"
unescape("%hh")
unescape("%u00h h")
(which is a string with .charCodeAt(0)= =n, however much sense that
makes).
[...]

The code point table would probably be identical across all these
commands, it's probably decided by the js engine itself.

<quote cite="ECMA 262, 3rd Ed. Section 6">
6 Source Text

ECMAScript source text is represented as a sequence of characters in
the Unicode character encoding, version 2.1 or later, using the UTF-16
transformation format. The text is expected to have been normalised to
Unicode Normalised Form C (canonical composition), as described in
Unicode Technical Report #15. Conforming ECMAScript implementations
are not required to perform any normalisation of text, or behave as
though they were performing normalisation of text, themselves.

SourceCharacter ::
any Unicode character

ECMAScript source text can contain any of the Unicode characters. All
Unicode white space characters are treated as white space, and all
Unicode line/paragraph separators are treated as line separators.
Non-Latin Unicode characters are allowed in identifiers, string
literals, regular expression literals and comments.
</quote>

It doesn't look like the page's own charset has any influence.

The/a character set asserted by an HTTP content type header would
probably be employed in deciding how to translate incoming javascript
source into the "of characters in the Unicode character encoding" that
is needed prior to the tokenisation of the code.

I didn't find a way
to force getCharCodeAt() to a specific code page neither.

<snip>

You wouldn't as by the time you are dealing with javascript you are
past the point where the normalisation to Unicode ahs happened and so
code pages are not an issue.

Richard.

[Bart Van der Donck]

Richard Cornford wrote:

<quote cite="ECMA 262, 3rd Ed. Section 6">
6 Source Text

ECMAScript source text is represented as a sequence of characters in
the Unicode character encoding, version 2.1 or later, using the UTF-16
transformation format. The text is expected to have been normalised to
Unicode Normalised Form C (canonical composition), as described in
Unicode Technical Report #15. Conforming ECMAScript implementations
are not required to perform any normalisation of text, or behave as
though they were performing normalisation of text, themselves.

SourceCharacter ::
any Unicode character

ECMAScript source text can contain any of the Unicode characters. All
Unicode white space characters are treated as white space, and all
Unicode line/paragraph separators are treated as line separators.
Non-Latin Unicode characters are allowed in identifiers, string
literals, regular expression literals and comments.
</quote>

I'll get back after my first ECMAScript study, okay :)

The/a character set asserted by an HTTP content type header would
probably be employed in deciding how to translate incoming javascript
source into the "of characters in the Unicode character encoding" that
is needed prior to the tokenisation of the code.

I had to read that sentence 5 times, but, yes, I'ld say this is a
correct representation. One side remark though. I'ld say browsers
should normally accept the stream in the offered character set, as you
said. For example, setting the output stream and <meta http-equiv/to
ASCII should prevent a character like 'é' to be displayed. And yes,
MSIE seems to implement this correctly:

http://www.dotinternet.be/temp/ascii.pl

But Firefox seems to throw away the charset rules, and display them
anyway. The code:

#!/usr/bin/perl
print <<'HTM'
Content-Type: text/html; charset=ascii

<html>
<body>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=ascii"/>
</head>
<body>
é
</body>
</html>
HTM

Interesting!

--
Bart

[RC]

mistral wrote:

>
Not fully clear with this encoding. So, what output encoding will
preferable to use for obfuscating: ASCII, European ASCII (ISO-8859-1),
or UNICODE (UTF-8 or UTF-16)? What with unescape? Most obfuscators use
this unescape.

<html><head>
<meta http-equiv=Content-Type content="text/html; charset=UTF-8">
</head>
<body>
do whatever you want

</body></html>

you can try charset=UTF-16, ... ,etc.