Paid Advertising
web application security lab

JavaScript Protection - A Collection Of Oddities

I was sort of bored and listless this evening and I decided to type in a phrase into a search engine just to see what I’d find, “JavaScript Protection” seemed like a good enough candidate. The first link I found in Yahoo was a link to the JavaScript Protection script collection on I spent a good hour looking over all of the scripts and I have to say, it’s a pretty impressive collection of oddities.

There are a few things on there that have no obvious flaws, like the JavaScript password creator. However, almost all of the others suffer from the same obvious problem. They rely on the fact that the user doesn’t view source to see the “encrypted” or otherwise obviously plaintext passwords in the source. There was one version of the script that I thought was vaguely clever and also incredibly scary in that it sends users to their password plus the .html extension. Nothing like keeping your password in plaintext on publicly accessible internet websites! There’s nothing new here, other than the fact that there is such an amazing collection of badly written code snippets in such a small space. Ugly!

8 Responses to “JavaScript Protection - A Collection Of Oddities”

  1. Spyware Says:

    This is the only one who is _a bit_ safe, it requires the hacker to reverse engineer the script. (I still want to do that some day).

    The rest of em javascript protections are like paper cuffs, one right click is enough to rip em apart.

  2. Awesome AnDrEw Says:

    I always loved these Javascript and VBScript password managers (I’ve written a few a long time ago in VBScript), because as you point out it’s entirely too easy to reverse engineer. Even those old “protect your HTML” Javascripts that’d encode your source, and then spew it out through document.write could easily be bypassed to get the source of the page.

  3. Awesome AnDrEw Says:

    Spyware, I believe that one would be most difficult to reverse engineer, but some what simple to brute force. You figure all the ASCII text is converted to their lowercase equivalents (if they’re non-numeric), and essentially all that takes place is the loop multiplies the string character by character. It slightly lessens the amount of attempts, or possible combinations you’ll have some script produce for you since the characters will fall between certain decimal values, which’ll allow you to ignore the other characters, and if the value of your string begins to become greater than that of the password or username you can also rule out any more characters that could possibly be used.
    Even so since the file name in question is the username and password in plaintext you’ll need to use some form of automation (it’ll quicken it) to put together every possible combination of those two, and check for the page.

  4. Ivan Says:

    More funny to me is when developers comment old/non-functional parts of code, that can be changed from some form on page ( and produce XSS ).

  5. maluc Says:

    You can’t really reverse engineer 100% .. but you can significantly reduce the possibilities by using some logic. As andrew said, those numeric values are just all the characters ASCII values multiplied together (so a password of AA has a code of 97*97). Adding the fact that it moves everything to lowercase makes it even easier.

    The way to partially reverse engineer it is to factor it out. the two codes are products of ASCII values ranging from 97 to 122 (add in valid special chars too that can appear in a filename, i’m exempting for simplicity) .. 6 of which are prime numbers, so you can automatically factor each of them out from the start: “aegkmq”

    using the example passwordcode 126906300 for the password “good”, factoring out the “g” (103) leaves a value of 1232100 ..
    Factors of 1232100: 1 2 3 4 5 6 9 10 12 15 18 20 25 30 36 37 45 50 60 74 75 90 100 111 148 150 180 185 222 225 300 333 370 444 450 555 666 740 900 925 1110 1332 1369 1665 1850 2220 2738 2775 3330 3700 4107 5476 5550 6660 6845 8214 8325 11100 12321 13690 16428 16650 20535 24642 27380 33300 34225 41070 49284 61605 68450 82140 102675 123210 136900 205350 246420 308025 410700 616050 1232100

    Wow, that seems unhelpful.. but it’s quite useful. Now find all prime numbers below 122, giving:
    2 3 37
    start with the biggest (37), and see all the possible multiples off it between 97 and 122.. that gives only the value 37*3 = 111.. or the letter ‘o’

    divide out that 37, (1232100/37=33,300) and repeat.

    For every password of normal lengths this will find all the letters, just in the wrong order. if any valid ASCII value was a multiple of another valid ASCII value, this would run into some problems.

    so now you have N number of letters in the wrong order.. leaving only 2^N possible arrangements. Even less with duplicates of one or more letters.

    In that example password “good”.. that would be 2^4=16 possible orders .. but because of the duplicate o’s theres actually only 12 to bruteforce:

    much nicer than a full bruteforce of i think k^((n^2)/2) .. where n is the max password length and k is the number of letters. Which in this case even if we knew it was exactly 4 letters, that would take an average of 38,081 possible passwords to multiply and check against the passwordcode. (i got that number by (26^4) / 12, assuming average spreading of the 12 possible valid passwords)

    That was long, but hopefully not too confusing.. the conclusion is that, any password can be reverse engineered quickly using prime numbers to find all the letters, then bruteforcing the website for all combinations of those letters.

  6. Spyware Says:

    *copies maluc’s post* hey, andrew and maluc thanks for those posts.

    But ehm *nodding at maluc* you see that this script takes more time/recources to bypass than just right click and view source. It will stop most users. Also, I am sure someone could improve the DHTML script, to make it harder for someone to reverse engineer.

  7. Awesome AnDrEw Says:

    I believe you’re physically limited when you try to implement any client-side password feature as in order for it to be client side it must be visible in the HTML, and therefore cannot truly be safe from any form of reverse engineering. The creator of the script points that out as well.

  8. Metal Says:

    It’s somewhat puzzling to see such a collection of password encryption scripts, none of which use any half-decent encryption algorithms.
    There are implementations of AES(1), RC4(2) and RSA(3) among others, written in javascript.
    It’s not terribly difficult to design something that generates a sha-256(4) hash from a password and uses that as a key to decrypt some AES-256 encrypted block of information.
    Whether you put the URL to another page in that block of information, or the secret recipe for your chili sauce is up to you.