I noticed on MetaFilter last night that it would appear that the company “Misssster Anderson” worked for in the original Matrix movie, Metacortex, has a web presence. Not only does it have a web presence, many of its partner companies and at least one employee does, too. All of these fictitious sites look to be hosted by the same fictitious hosting company. This web of fake pages unfolds to a strange game, being tracked by http://free.pages.at/areku/meta/index.htm. I got kind of sucked into it when I noticed a couple of new things… First, the Flash application for employee logins on the Metacortex site requests a list of usernames and passwords from a server, but gets a 404 (thank you, tcpdump!)–which means it either cannot work at present or this is a red herring. Second, the member login form on the Underscore Hosting site checks for a single hard-coded name and hard-coded password in JavaScript (using a one-way hash algorithm).
I decided to run a wordlist against the algorithm, with no luck. My computer spent the night running a brute-force against the algorithm and is up to seven letters, but so far has not found anything. If anyone wants to take a look at the code I used to do this, it is available at https://netninja.com/files/underscorehack/. The relevant comments follow from the top of the file follow…
// underscorehack.c // Concieved, written, and directed by Brian Enigma // Version 1.0 // Copyright 2003, Brian Enigma // Released under the GPL /*=====================================================================*\ In order to understand the context of the following comments and article, I would suggest you study up on the weird Matrix-related "game" that seems to have appeared on the internet. I originally learned about it from MetaFilter (http://www.metafilter.com/mefi/28708), which in turn had a comment link to http://free.pages.at/areku/meta/index.htm. ===================================================================== The following program is used to guess passwords for the JavaScript at http://www.underscorehosting.com/members.html. This JavaScript will accept a username and password from a web form. Each letter is converted to an ASCII value. All of the number values for the letters in the username are multipled together, giving a very large number. A similar transform is applied to the password. These two hash values are compared against constants (967612988160000 for the username and 17390546100000 for the password). If they do not match, an error is displayed. If they do match, whatever the password was gets ".htm" appended to it and you get redirected to that page. Goal: The username is inconsequential (but may give a hint to what the password may be), but guessing the password will lead us to the correct "login" page. There are several different methods that can be employed to reach this goal. Method 1: Take a word list, attempt to hash every word, then compare it to the results. One thing the following program does is this. I tried it with the standard OS X word list file, with no positive results. You can try it on your own--you will need to put a dictionary text file named "words" in the current directory, then comment out the call to checkWordList in main(). Method 2: Brute force attempt of every letter/number combination. By default, that is what the following program does, going from "a"..."z", "aa"..."az", "ba"..."bz", "ca"..."cz"...etc. Currently this is running in the background of my machine and I am up to "gx3aaaa". Method 3: Find the factors of the very large password number. Combine those factors together to form valid ASCII values and rearrange the resulting letters. The following program does not address this--finding the primes of an "unsigned long long" number, then performing permutations and combinations is not exactly a trivial task. Notes: * The search space for the password is "all lowercase letters," "all numbers," period, and underscore. Uppercase letters are not used, since the password is converted to lowercase by the JavaScript before hashing and comparing. * It occurs to me now that the password could be entirely URL escaped, which would mean it would be three times as big as it normally would be. For instance, if the final destination page were "ninja.htm", the password could be "ninja", but could just as easily be "%6e%69%6e%6a%61", which would lead to the same web page. It would also make the password more difficult to guess and yield a much larger hash value (and make search more difficult). Perhaps a wordlist search could be performed against URLEncoded words? Perhaps a brute-force search could be made against URLEncoded strings? This would, of course, weight the factors of the original number to contain many multiples of 37 (the ASCII value of "%"). * For what it's worth, here is the relevant piece of the original JavaScript code: password = document.password1.password2.value.toLowerCase() username = document.password1.username2.value.toLowerCase() passcode = 1 usercode = 1 for(i = 0; i < password.length; i++) { passcode *= password.charCodeAt(i); } for(x = 0; x < username.length; x++) { usercode *= username.charCodeAt(x); } if(usercode==967612988160000&&passcode==17390546100000) { window.location=password+".htm"} else{ alert("Invalid Username/Password")} } \*=====================================================================*/