446,179 Members | 1,144 Online Need help? Post your question and get tips & solutions from a community of 446,179 IT Pros & Developers. It's quick & easy.

# what this encryption used?

 P: n/a Can anyone help to identify what this encryption used in this script? Oct 10 '06 #1
4 Replies

 P: n/a On 2006-10-10, mistral 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])<>=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). Oct 10 '06 #2

 P: n/a Spamless wrote: On 2006-10-10, mistral wrote: Can anyone help to identify what this encryption used in this script? 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])<>=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. Oct 10 '06 #3

 P: n/a On 2006-10-10, mistral >It looks like a lookup (converting the original encryptedtext to a string of numbers from 0 through 63),base64 decoding of that "base 64" numberand 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.) Oct 11 '06 #4

 P: n/a 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. Oct 11 '06 #5

### This discussion thread is closed

Replies have been disabled for this discussion. 