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> 4 2032
On 2006-10-10, mistral <po*******@softhome.netwrote:
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>
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).
Spamless wrote:
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>
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).
----------
thanks for detailed answer. Not clear however, why not use just base64.
m.
On 2006-10-10, mistral <po*******@softhome.netwrote:
>
>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:
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.)
Spamless wrote:
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:
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.)
-----------------
Is this script done use some obfuscation tool? Of this is custom
obfuscation routine? I would like to see this obfuscator.
m. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Protoman |
last post by:
I'm trying to write an encryption program, and it doesn't produce the
right output; "GOOGLE" encrypted w/"GOOGLE" IS NOT "ee".
Here's the code:
namespace
{
const char vTable=
{...
|
by: Bonj |
last post by:
I was in need of an encryption algorithm to the following requirements:
1) Must be capable of encrypting strings to a byte array, and decyrpting
back again to the same string
2) Must have the same...
|
by: viduras |
last post by:
Hi,
Is there any way in .NET/C# where double encryption can be used in
exchanging a symmetric key ?
If I ellaborate it further, say in a client server application, the
symmetric key that...
|
by: Alan Silver |
last post by:
Hello,
I am writing a page where sensitive data is collected (over SSL) and
stored in a database. I have been looking at the .NET encryption
classes, but am a bit confused as to which is best...
|
by: Mark Rae |
last post by:
Hi,
Picking your collective brains again, this time regarding the storage of the
key used in symmetric encryption.
Let's say you have a requirement to add encryption to a C# project, so you...
|
by: pintu |
last post by:
Hello everybody..
I hav some confusion regarding asymmetric encryption.As asymmetric
encryption it there is one private key and one public key.So any data
is encrypted using private key and the...
|
by: damod.php |
last post by:
what's the Basic Encryption method used in mysql,
whats iner join whats outer join ,diff b/w.what are the encryption
methods used to encrypt the user name and password.in php/mysql
|
by: =?Utf-8?B?bWljcm9ob2Y=?= |
last post by:
Short version:
Is there a way to configure (preferably programmatically) the max encryption
strength that will be used by the framework when connecting to a particular
SSL-protected web service?
...
|
by: John Williams |
last post by:
I've written a simple program to do XOR encryption as my first foray
into understanding how encryption works. The code compiles fine, however
it segmentation faults on every run. using gdb to...
|
by: j1mb0jay |
last post by:
I have had to create a simple string encryption program for coursework, I
have completed the task and now have to do a write up on how it could be
improved at a later date. If you could look...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |