Javascript: Secret Area!!

Yes. This is true! Garfield tells me that this is a code with the Name "Site Protector v2" and it's unbreakable. The only possibility is Bruteforce.
The code comes from an old Friend and i didn't know that the code is called "Site Protector v2".

But it's a good example to see how safe javascript is!

Here's a working version: http://www.javascriptsource.com/passwor … 23741.html

I'm not going to brute this, cause my firefox stop working after a certain time.  I changed dom.max_chrome_script_run_time and dom.max_script_run_time to 0 and it keeps stop working after a time.

I think that a hint for the used charset a-z,  A-Z, Numbers is usefull.

Longer passwords still keep unbreakable with bruteforce. Maximum size for this script is 16 chars.
Only possible way at this time is trying a dictionary at my opinion.

Zuletzt bearbeitet von Garfield (14.06.2013 14:42:54)

I agree that there are different results with internet-explorer and firefox.

I did a brute with german and english dictionary without positive results with internet-explorer.

It's interesting why there are such differences within the javascript engines.

I know that the code is from 1999/2000. I'll try to encrypt "abcd" later in a virtual machine with Windows 2000 and ie/ff. The result could help us maybe too.

Zuletzt bearbeitet von Garfield (15.06.2013 10:29:11)

Update: An old Firefox from 2005 gives me same results as Internet-Explorer.

The solution from this challenge is not a word from english/german dictionary generated with IE. (bruteforce tested)

C-Tex, please tell us with which browser and version the password has been generated and something about dictionary or password length and it's charset.

IE9 of all browsers... arghh... VirtualBox.. here we go.. :-)

** UPDATE **
Looks pretty impossible.. reversing the algorithm falls dead when you reach the
"for(count=0;count!=basecode.length;count++)" - loop

I see no way to reverse this (or get an close reverse approximation), meaning we would have to build a table with all possible inputs and their resp. output. I checked with a few values (encrypting) and it seems the length of this loop is usually around 8. Meaning we would have to BF upto 8 characters from the "acharset"... in IE9... :s

To BF a password of 10 characters with charset 0-9A-Z seems pretty painful too. I guess the only option is a dictionary attack with uppercase and leetspeak replacements... in IE9... :s.

Zuletzt bearbeitet von mego (18.06.2013 17:39:19)

I *almost* got a remake build in Java.. sadly there are still some rounding bugs in IE that I don't know how to do in Java.. . So close!!

Stupid thing is that if it only differs a little the results will be completely different..

No luck for me yet.. the previous "dictionary" (german, uppercase with digits) seemed easier to me.

@C-tecx: can you provide the encrypted string for "abcd" (or any other known plaintext). That way everyone can check their implementation/browser for the correct result.

Another option would actually be to "fix" the "cutoff()" function. This is where all the rounding errors happen.

Solved! :-)

@C-tecx: I like the solution word :-) hehe