Doug Wyatt January 4, 2018 at 10:38 PM
I'm flabbergasted. That's my Alto disk you broke into!
The APL stuff is surely related to some work I did with Leo Guibas, showing why lazy evaluation would be a really good idea for implementing APL: see Compilation and delayed evaluation in APL, published January 1978. (That paper gives me an enviable Erdős number of 3, since Leo is a 2.) I'm sure it's not a complete APL implementation, just a proof of concept. It happens that my very first part-time job at PARC, in 1973, involved writing decision analysis software in APL -- on a timesharing system!
Given the AATFDAFD hint, I'd guess the real password is ADDATADFAD. This derives from a project I did with Jef Raskin at UCSD in 1974. (He mentioned it in this interview.) The Data General Nova we were working with produced some garbled message with ADDATADFAD where it should have said ADDITIONAL, and it was a running joke ever after. Strange, the things that occupy some brain cells for over 40 years.
Thanks for an amusing blast from the past.
-- Doug Wyatt (Xerox PARC 1973-1994)
The password being there, as the people in the bike store where I bought the lock told me, to keep the honest people honest.
If you have IRIX installation CD then you can even set the new password, but you probably don't have it? You can also put the disk into another SGI, also not what everyone has. If guest account is enabled, login with guest (no password) and just cat the /etc/passwd. If guest account is not enabled, you can do the cat via sash, which is a bit more compicated, like this: https://web.archive.org/web/20151023042224/http://crackaddic...
Once you have your hash, do it with John the Ripper (GPU version). Store the password int a text file in format of root:hash and run john the ripper on it. Encryption is, AFAIK, DES so use john --format=des passwd.txt if john doesn't autodetect which encryption it is (I remember I had to set it manually). It can take awhile, depending on the GPU, but not that long.
If you run into trouble, I can have a look. I think I wrote down somewhere what to do, in case I need it again.
Probably what I'll do, though, is set up SCSI on a linux box somewhere and try to xxx the shadow, seems to be the smoothest route .. don't wanna mess too much, because after all, 20 years later .. I still wanna boot my old SGI like the good ol' days. :)
Next you would use something like hashcat  to bruteforce the password.
Better than that only the Windows LM Hashes
But this is really the antithesis of what a zero-day originally was, which was a crack circulated on or even before the release day of software. The Alto is 45 years old :)
Odd how words and phrases can change so much over a short period of time that they invert their meaning.
 that's what it meant in the early / mid 1990s when I was peripherally involved. Now it seems to mean 'zero days of notification to the vendor'.
I think 'zero days since a patch has been released' is probably more accurate.
Personally, torrents fulfill my needs these days, I can't be bothered to Sneakernet, DDC or FXP anymore.
Let’s just call it 2¹⁴ days and be done with it.
Today with digital distribution even if it's for patches only you don't care about the game going gold the DVD could contain a build that is utterly irrelevant pretty much every new install from disk requires a day 1 patch that can be often as large as downloading the whole from scratch (pretty much every console owner knows this, PC games also get a day one patch but digital distribution is a given for the PC market these days).
So zero-day for games at least isn't that important anymore, also DRM is harder to crack these games some games take months to crack, some don't get cracked at all, some rely on a weaken DRM version to be released (e.g. STEAM) down the line that can be cracked more easily.
For DVDs/BR today this also often happens you have full BR rips often weeks before the official release date, sometimes months just because they are already ready just waiting on the right time to go on sale or for some online distribution exclusivity deal to end.
Early builds that might not function outside of the internal environment aren't much of a deal the last leak I remember that got a scene release was probably the Doom 3 Alpha.
We'd then run some cassettes off that master to validate they loaded, some of the copy protection was picky about the duplication quality and speed. They'd then start production and the finished product would be on the shelves in a week or two at most.
It was a fun and very interesting time visiting all those places. I went up to Telford once and was stuck there for a while as there was a mastering problem and we had to play with the copy protection. Most of the times it was a place by the A4 near Chiswick/Hammersmith.
It is because they got something in return: access to the private FTP servers used by the group, which means they get to download their releases before they appear anywhere else.
This is especially attractive to people who manage DDL or streaming sites which earn a lot of $$$ from intrusive/malicious ads...
It is also a big deal for private torrent tracker operators and/or uploaders. If you get Razor1911 releases before any other tracker, people will want to get in ;)
As someone who was a kid who actually cared about the games, it just seemed pointlessly tiresome to be worth it at that point.
IIRC, the Xerox Pilot OS was purely cooperative multitasking with a single shared address space.
> This attack is called XeroDay
Hmm, if not to defend against rainbow tables... why were the passwords salted back then?
One problem with hashed passwords is if two users have the same hash, then you know they have the same password. A solution (invented in Unix) is to hash some random bytes (called salt) along with the password to yield the stored hash. Since different users will have different salt, the hashes will be different even if the passwords are the same. (Of course you need to store the salt along with the hash in order to check passwords.) Like Unix, the Alto used salted and hashed passwords.