1

(2 Antworten, geschrieben in Bugs / Fehler)

There are more possible solutions.

2

(19 Antworten, geschrieben in Hints / Lösungsansätze)

Solved! :-)

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

3

(19 Antworten, geschrieben in Hints / Lösungsansätze)

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.

4

(19 Antworten, geschrieben in Hints / Lösungsansätze)

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.. sad. So close!!

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

5

(19 Antworten, geschrieben in Hints / Lösungsansätze)

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.

6

(19 Antworten, geschrieben in Hints / Lösungsansätze)

But then you still need to bruteforce in every possible browser.. because the algorithm is browser dependent!
For starters it would be nice to know which browser was used to generate the hash, then we can re-implement the exact behavior in a different language which allows for faster BF. Moreover, it might be possible to do a little bit smarter of a BF if we partially reverse the algorithm..

Today I ran a dictionary attack in FF, after couple of hours nothing turned up. It's pretty slow you know...

7

(19 Antworten, geschrieben in Hints / Lösungsansätze)

Here is another one:

http://www.jsmadeeasy.com/javascripts/P … sample.htm

8

(19 Antworten, geschrieben in Hints / Lösungsansätze)

Yes, I understood.

I am ok for brute forcing the password, but what I am saying is that depending on the browser you get different encryptions!! That will force me to bruteforce in all different browsers out there and hopefully none of them changed their javascript implementation :s.... Moreover, I truly hope it doesn't also depend on the PC specs (32-bit/64-bit). The challenge is build upon the imprecision of doubles... :s

Could you at least tell us in which browser this can be solved? Hopefully the pass is short, bruteforcing in browsers is usually very slow.. sad

mego

9

(19 Antworten, geschrieben in Hints / Lösungsansätze)

Hi all,

This challenge is impossible. It depends heavily on the precision/scale of doubles. ECMA defines a standard, but imprecision is everywhere. Different browsers will give different results. I tested Opera and Firefox and they give different result, e.g.

When encrypting "abcd"...
... in Opera: kNGUNBWC
... in FireFox: qkVSQxZ
... in Internet Explorer: JJou0VzZ

It's quite an interesting challenge, but I doubt anyone will have much fun deciphering the internal browser handling of doubles.

Hopefully I didn't overlook something.
mego

10

(5 Antworten, geschrieben in Hints / Lösungsansätze)

So many possible solutions.. it seems like it will be a German word. I checked a dictionary, found some words, made the necessary modifications (if you know what i Mean) but no luck.

Any ideas?

11

(5 Antworten, geschrieben in Hints / Lösungsansätze)

Ok, my bad. Now I have an "Access granted", but there are many solutions.. time to try and find the most sensible one....

Thanks though for checking!!

Hi,

I am very sceptical whether this challenge is even possible. I am reverse engineering the javascript and I only got as far as the "temp" number just before the final loop. From the last few digits of that number you should be able to get a step further again, but none of the combinations actually converts into those digits.....

Could you please check if  the javascript in this challenge actually works?

mego

PS: I can give more details, but I don't want to spoil the fun.