Invalid Username/Password

Please note that all blog posts before 8 April 2007 were automatically imported from LiveJournal.  To see the comments and any LiveJournal-specific extras such as polls and user icons, please find the source posting at

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 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 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 (, which in turn had a
comment link to


The following program is used to guess passwords for the JavaScript at  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.

 * 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

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);


alert("Invalid Username/Password")}

Posted in: Dear Diary

Leave a Reply

Your email address will not be published.