what this encryption used?

M

mistral

Can anyone help to identify what this encryption used in this script?

<html>
<body>
<script type="text/javascript" language="JavaScript">
function decrypt_p(x){
var l=x.length,
b=1024,
i,j,r,
p=0,
s=0,
w=0,
t=Array&
#40;63,47,29,11,10,49,16,9,42,48,0,0,0,0,0,0,41,57,58,45,44,31,15,28,7,2,62,36,3
5,14,34,51,18,17,39,13,33,59,23,0,27,26,46,0,0,0,0,61,0,24,5,38,3,50,37,22,1,20,
55,6,25,32,43,21,4,8,40,54,53,12,30,56,60,52,19);

for (j=Math.ceil(l/b);j>0;j--) {
r='';
for (i=Math.min(l,b);i>0;i--,l--) {
w|=(t[x.charCodeAt(p++)-48])<<s;
if(s) {
r+=String.fromCharCode(165^w&255);
w>>=8;
s-=2
} else {
s=6
}
}
document.write(r)
}
}

decrypt_p(& ..=encrypted code here=..")
</script>
</body>
</html>
 
G

Guest

Can anyone help to identify what this encryption used in this script?

<html>
<body>
<script type="text/javascript" language="JavaScript">
function decrypt_p(x){
var l=x.length,
b=1024,
i,j,r,
p=0,
s=0,
w=0,
t=Array&
#40;63,47,29,11,10,49,16,9,42,48,0,0,0,0,0,0,41,57,58,45,44,31,15,28,7,2,62,36,3
5,14,34,51,18,17,39,13,33,59,23,0,27,26,46,0,0,0,0,61,0,24,5,38,3,50,37,22,1,20,
55,6,25,32,43,21,4,8,40,54,53,12,30,56,60,52,19);

for (j=Math.ceil(l/b);j>0;j--) {
r='';
for (i=Math.min(l,b);i>0;i--,l--) {
w|=(t[x.charCodeAt(p++)-48])<<s;
if(s) {
r+=String.fromCharCode(165^w&255);
w>>=8;
s-=2
} else {
s=6
}
}
document.write(r)
}
}

decrypt_p(& ..=encrypted code here=..")
</script>
</body>
</html>
Click to expand...



It looks like a lookup (converting the original encrypted
text to a string of numbers from 0 through 63),
base64 decoding of that "base 64" number
and then a simple XOR.



The "for (j=Math.ceil(l/b);j>0;j--)" loop just works in blocks
of 1024 characters, so let's ignore that and get into the
"for (i=Math.min(l,b);i>0;i--,l--)" loop.

s will start at 0 and then to 6 4 2 0 6 4 2 0 ...
The first step is always to convert the character in the string
to a number based at "0" (the string "0" has ascii value 48)
and look that up in a table (the "t array" - a simple substitution
lookup). While there are duplicates, the numbers in the "t array"
(in your prior post) ranged from 0 through 63 (it covers all those
numbers) so we have several values which might result in the same
falue but the characters we get (t[x.charCodeAt(p++)-48]) will all
be integers from 0 through 63 suggesting base64 encoding.

Base64 decoding will drop some characters (4 base 64 encoded characters
become 3 ascii characters) and the s values show that. There are four
values through which s loops (starting with 0)
0 6 4 2 0 6 4 2 0 ...
(if (s) {... s-=2} else {s=6})
and only for s not zero do we get an extra character in the decoded
string
if(s) {r+=...}

So ... 64 possibled encoded characters, for every four encoded characters
we get three decoded characters - again, strongly suggestive of base64
decoding.

Let's look at the code ...
for the first character (s=0) we just with that in "w"
(w|=(t[x.charCodeAt(p++)-48])<<s where s=0 and w=0 initially)
The next time through, (s=6) the next character is shifted six
bits to the left and added (ORed) to this initial character
(w|=(t[x.charCodeAt(p++)-48])<<s;) with the result that w's
last eight bits consist of the last two bits of the second
character (after the lookup) followed by the six bits (the
lookup value always only has six bits being from 0 through 63)
of the first character. After the simple XOR, we take the last
eight bits (r+=String.fromCharCode(165^w&255)). So a lookup,
construct 8 bits from six bits of the first and the low two
bits of the second character and and XOR.

Then we drop the character we just got (w>>=8) keeping (in w
now) only the bits left after this shift (we dropped the
first encoded character's six bits and two more from what
we got by shifing the second character six bits to the
left and now shifting 8 bits to the right). The result,
since the second encoded character (after the lookup)
had only six bits (0-63) is the top four bits of this.

We lookup the next encoded character (to get another number
from 0-63) and shift that (s is now 4) four bits to the
left and add (OR) it to the four high bits of the second
encoded character (after lookup).

The XOR (and truncated to the last 8 bits,
String.fromCharCode(165^w&255), creates the next decoded
character from the high four (of the six) bits of the
second encoded character and the low four (of the six bits)
of the third encoded character (after lookup) and then that
(after the decoded character is appended to the string)
loses its last 8 bits (the decoded character) leaving the
high two bits of the third encoded (after lookup) character
in w and now s=2.

The four encoded character is shifted (s=2) two to the left
and added (ORed) with this to get the third decoded character
(its value is obtained from the high two of six bits of the
third character along with the six bits of the fourth encoded
character after lookup).

Yep ... that's just a base64 decoder (after the lookup in the
t Array to get six bit values and before the final simple
XOR and extraction of the character (last eight bits) 165^w&255).
 
M

mistral

Spamless said:
On 2006-10-10, mistral wrote:
Can anyone help to identify what this encryption used in this script?
<html>
<body>
<script type="text/javascript" language="JavaScript">
function decrypt_p(x){
var l=x.length,
b=1024,
i,j,r,
p=0,
s=0,
w=0,
t=Array&
#40;63,47,29,11,10,49,16,9,42,48,0,0,0,0,0,0,41,57,58,45,44,31,15,28,7,2,62,36,3
5,14,34,51,18,17,39,13,33,59,23,0,27,26,46,0,0,0,0,61,0,24,5,38,3,50,37,22,1,20,
55,6,25,32,43,21,4,8,40,54,53,12,30,56,60,52,19);

for (j=Math.ceil(l/b);j>0;j--) {
r='';
for (i=Math.min(l,b);i>0;i--,l--) {
w|=(t[x.charCodeAt(p++)-48])<<s;
if(s) {
r+=String.fromCharCode(165^w&255);
w>>=8;
s-=2
} else {
s=6
}
}
document.write(r)
}
}

decrypt_p(& ..=encrypted code here=..")
</script>
</body>
</html>
Click to expand...


It looks like a lookup (converting the original encrypted
text to a string of numbers from 0 through 63),
base64 decoding of that "base 64" number
and then a simple XOR.


The "for (j=Math.ceil(l/b);j>0;j--)" loop just works in blocks
of 1024 characters, so let's ignore that and get into the
"for (i=Math.min(l,b);i>0;i--,l--)" loop.
Click to expand...
s will start at 0 and then to 6 4 2 0 6 4 2 0 ...
The first step is always to convert the character in the string
to a number based at "0" (the string "0" has ascii value 48)
and look that up in a table (the "t array" - a simple substitution
lookup). While there are duplicates, the numbers in the "t array"
(in your prior post) ranged from 0 through 63 (it covers all those
numbers) so we have several values which might result in the same
falue but the characters we get (t[x.charCodeAt(p++)-48]) will all
be integers from 0 through 63 suggesting base64 encoding.
Click to expand...
Base64 decoding will drop some characters (4 base 64 encoded characters
become 3 ascii characters) and the s values show that. There are four
values through which s loops (starting with 0)
0 6 4 2 0 6 4 2 0 ...
(if (s) {... s-=2} else {s=6})
and only for s not zero do we get an extra character in the decoded
string
if(s) {r+=...}
Click to expand...
So ... 64 possibled encoded characters, for every four encoded characters
we get three decoded characters - again, strongly suggestive of base64
decoding.
Click to expand...
Let's look at the code ...
for the first character (s=0) we just with that in "w"
(w|=(t[x.charCodeAt(p++)-48])<<s where s=0 and w=0 initially)
The next time through, (s=6) the next character is shifted six
bits to the left and added (ORed) to this initial character
(w|=(t[x.charCodeAt(p++)-48])<<s;) with the result that w's
last eight bits consist of the last two bits of the second
character (after the lookup) followed by the six bits (the
lookup value always only has six bits being from 0 through 63)
of the first character. After the simple XOR, we take the last
eight bits (r+=String.fromCharCode(165^w&255)). So a lookup,
construct 8 bits from six bits of the first and the low two
bits of the second character and and XOR.
Click to expand...
Then we drop the character we just got (w>>=8) keeping (in w
now) only the bits left after this shift (we dropped the
first encoded character's six bits and two more from what
we got by shifing the second character six bits to the
left and now shifting 8 bits to the right). The result,
since the second encoded character (after the lookup)
had only six bits (0-63) is the top four bits of this.
Click to expand...
We lookup the next encoded character (to get another number
from 0-63) and shift that (s is now 4) four bits to the
left and add (OR) it to the four high bits of the second
encoded character (after lookup).
Click to expand...
The XOR (and truncated to the last 8 bits,
String.fromCharCode(165^w&255), creates the next decoded
character from the high four (of the six) bits of the
second encoded character and the low four (of the six bits)
of the third encoded character (after lookup) and then that
(after the decoded character is appended to the string)
loses its last 8 bits (the decoded character) leaving the
high two bits of the third encoded (after lookup) character
in w and now s=2.
Click to expand...
 
G

Guest

thanks for detailed answer. Not clear however, why not use just base64.
Click to expand...

I think there are a few differences. As Javascript does not
have a built in base64 decoder, the author had to write his
own and, while at it, he made some changes (the order of
the bits, the "base64 digits"-the characters which are mapped
to the numbers from 0-63, and the final XOR used at the end).


If you have four regular base64 encoded characters which are
decoded to three decoded 8-bit (base256) characters and the
four encoded characters are A B C D with bits (6 bits each)
aaaaaa, bbbbbb, etc. I believe that the (usual base64) decoding
is:

Write down the four characters six bit patterns in sequence
and take the first, second and third sequences of eight bits
to get three base256 (8 bit) characters from four base64
(6 bit characters):

aaaaaabbbbbbccccccdddddd
^^^^^^^^
^^^^^^^^
^^^^^^^^
First decoded
Second decoded
Third decoded

while I *think* that this code is a bit different

ddddddccccccbbbbbbaaaaaa
^^^^^^^^
^^^^^^^^
^^^^^^^^
First decoded
Second decoded
Third decoded


(start, s = 0, with the first character:
aaaaaa
set s=6, get the next character and shift by s (six bits)
and OR with the first
bbbbbbaaaaaa
extract the last eight bits (and XOR with 165)
bbbbbbaaaaaa
^^^^^^^^
First decoded

drop that last byte (the one we got, shift right 8 bits,
the >>8 code)
bbbb
get the next character (s=4) and shift by s (four bits)
and OR with what we have

ccccccbbbb
and extract the low eight bits
ccccccbbbb
^^^^^^^^
Second decoded
and drop them
cc
then get the next character (s=2) and shift (by s=2)
ddddddcc
^^^^^^^^
Third decoded)


In any case it is "a" base64 decoding but the regular base64 encoding uses a
particular set of characters which are mapped to the numbers from 0-63 (the
base64 "digits" which is a different set from those used in UUencoding which
is a different set from those used in XXencoding all of which are "base64"
encodings) while this code uses a different set defined by the lookup array
(and in which several different characters can map to the same "base64 digit"
- e.g. the number "0" appears as an array value several times in the
"t Array" in the earlier post).

So, one cannot simply use a base64 decoder (even after a simple substitution
to use the "correct" base64 "digits") and would apparently need to do some
byte swapping (due to the different order, from right to left instead of
left to right, for the decoding). Even then the decoded string would only
"almost" be right, needing to have the characters XORed as the final step.

The code is not designed to be trivial to decode using some other programme
(but, heck, one can run the code itself using a Javascript interpreter, so
one does not have to understand it) but is not going to be sufficient to
protect or hide some content from anyone who is either determined to get it
or wise as to using a Javascript interpreter to run the included code on the
page.

(When I wrote a base64 decoder and encoder I (for the decoder) put four
base64 characters together as one 24 bit string and then extracted the
three eight bit characters from that rather than playing games to extract
them one at a time. It makes it clearer what is being done, but take your
choice based on your programming style. In this case the intent was to
obfuscate what is being done rather than to make clear what the encoding
is.)
 
M

mistral

Spamless said:
On 2006-10-10, mistral wrote:

It looks like a lookup (converting the original encrypted
text to a string of numbers from 0 through 63),
base64 decoding of that "base 64" number
and then a simple XOR.


thanks for detailed answer. Not clear however, why not use just base64.

I think there are a few differences. As Javascript does not
have a built in base64 decoder, the author had to write his
own and, while at it, he made some changes (the order of
the bits, the "base64 digits"-the characters which are mapped
to the numbers from 0-63, and the final XOR used at the end).

If you have four regular base64 encoded characters which are
decoded to three decoded 8-bit (base256) characters and the
four encoded characters are A B C D with bits (6 bits each)
aaaaaa, bbbbbb, etc. I believe that the (usual base64) decoding
is:
Click to expand...
Write down the four characters six bit patterns in sequence
and take the first, second and third sequences of eight bits
to get three base256 (8 bit) characters from four base64
(6 bit characters):
Click to expand...
aaaaaabbbbbbccccccdddddd
^^^^^^^^
^^^^^^^^
^^^^^^^^
First decoded
Second decoded
Third decoded
Click to expand...
while I *think* that this code is a bit different
Click to expand...
ddddddccccccbbbbbbaaaaaa
^^^^^^^^
^^^^^^^^
^^^^^^^^
First decoded
Second decoded
Third decoded

(start, s = 0, with the first character:
aaaaaa
set s=6, get the next character and shift by s (six bits)
and OR with the first
bbbbbbaaaaaa
extract the last eight bits (and XOR with 165)
bbbbbbaaaaaa
^^^^^^^^
First decoded
Click to expand...
drop that last byte (the one we got, shift right 8 bits,
the >>8 code)
bbbb
get the next character (s=4) and shift by s (four bits)
and OR with what we have
Click to expand...
ccccccbbbb
and extract the low eight bits
ccccccbbbb
^^^^^^^^
Second decoded
and drop them
cc
then get the next character (s=2) and shift (by s=2)
ddddddcc
^^^^^^^^
Third decoded)

In any case it is "a" base64 decoding but the regular base64 encoding uses a
particular set of characters which are mapped to the numbers from 0-63 (the
base64 "digits" which is a different set from those used in UUencoding which
is a different set from those used in XXencoding all of which are "base64"
encodings) while this code uses a different set defined by the lookup array
(and in which several different characters can map to the same "base64 digit"
- e.g. the number "0" appears as an array value several times in the
"t Array" in the earlier post).
Click to expand...
So, one cannot simply use a base64 decoder (even after a simple substitution
to use the "correct" base64 "digits") and would apparently need to do some
byte swapping (due to the different order, from right to left instead of
left to right, for the decoding). Even then the decoded string would only
"almost" be right, needing to have the characters XORed as the final step.
Click to expand...
The code is not designed to be trivial to decode using some other programme
(but, heck, one can run the code itself using a Javascript interpreter, so
one does not have to understand it) but is not going to be sufficient to
protect or hide some content from anyone who is either determined to get it
or wise as to using a Javascript interpreter to run the included code on the
page.
Click to expand...
(When I wrote a base64 decoder and encoder I (for the decoder) put four
base64 characters together as one 24 bit string and then extracted the
three eight bit characters from that rather than playing games to extract
them one at a time. It makes it clearer what is being done, but take your
choice based on your programming style. In this case the intent was to
obfuscate what is being done rather than to make clear what the encoding
is.)
Click to expand...
-----------------

Is this script done use some obfuscation tool? Of this is custom
obfuscation routine? I would like to see this obfuscator.

m.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

what code encoded in this snippet? 2
Unknown javascript appeared in a clients home page 4
strange js function on my pages 2
Decoder for obfuscated code? 3
Blue J Ciphertext Program 2
What "might" I be doing wrong with this snippet? 6
Issue with textbox script? 0
ChatGPT will make us Job(Home)less 3

Members online

Total: 86 (members: 1, guests: 85)
Robots: 102

Forum statistics

Threads
474,263
Messages
2,571,064
Members
48,769
Latest member
Clifft

Latest Threads

Top