sunny computers, part 2

previously we looked at some sun sparc machines for the first time. we got two of the five running, and managed to dump the ide-based Ultra 5 with a usb-to-ide adapter, but none of the scsi-based machines.

since then, we (+bkn) have cracked the root password of the Ultra 5, dumped most of the remaining machines, got the dead SS5 working, and started building an adapter to use usb input devices with the sun 8-pin mini-din interface.

hashcatting the Ultra 5

solaris uses the classic salted-des-based crypt(3), which in theory would make cracking the root password pretty easy. i used my RX 6650 XT (~147 MH/s), nathaniel his RX 6800 (~582 MH/s), and kieran his RX 6700 XT (~500 MH/s).

$ hashcat --session luds -m 1500 -w 2 --increment -a 3 -1 \?l\?u\?d\?s 7GX.9SY2Pb6sY \?1\?1\?1\?1\?1\?1\?1\?1

what the hashcat options meant

• --session gives this job a name that can be used with --restore
• -m 1500 is salted-des-based crypt(3)
• -w 2 competes somewhat aggressively with other gpu work
• --increment automatically tries prefixes of \?1\?1\?1\?1\?1\?1\?1\?1
• -a 3 is mask attack mode
• -1 \?l\?u\?d\?s defines \?1 as any lower or upper or digit or symbol
• 7GX.9SY2Pb6sY is the salted hash
• \?1\?1\?1\?1\?1\?1\?1\?1 means try eight characters matching \?1, which is the maximum for this hashing algorithm anyway

the good news was, my amd gpu Just Worked™ on nixos with minimal config, whereas hashcat was (as far as i can tell) completely broken for nvidia gpus.

hardware.opengl.extraPackages = with pkgs; [
  rocm-opencl-icd
  rocm-opencl-runtime
];

the bad news was, the password was going to be the (maximum) eight characters, and our hash rates were bleak. to use mine as an example:

?l?d      (26+10)^8/147000000/86400
        = .222120646 days
?l?u?d    (26+26+10)^8/147000000/86400
        = 17.191051397 days
?l?d?s    (26+10+33)^8/147000000/86400
        = 40.454016631 days
?l?u?d?s  (26+26+10+33)^8/147000000/86400
        = 522.345388707 days

so we each tried something different. nathaniel stuck with ?l?u?d?s (full ascii) but switched to an RTX 2060 (~647 MH/s), kieran specialised with rockyou-7-2592000.hcmask, and i specialised with ?l?u?d (no symbols). it took us almost two days, but we did it! the password for 7GX.9SY2Pb6sY was G1tfoGro.

dumping the scsi drives

in the pc world of the 90s, ide reigned supreme, but scsi was the standard pretty much everywhere else, including old macs and most of our SPARCstations.

the only time i had ever worked with a scsi hard drive was when dumping the proliant 800, but i managed to do that in situ (with great difficulty) by booting damn small linux and attaching an ide hard drive. neither of those things are available to our SPARCstations, so we needed a different approach.

we hadn’t really worked with scsi drives much, only ide. brock and nathaniel had scsi controller cards, and i had some cables, but none of us had the single connector for both data and power (sca). thankfully the adapter we ordered arrived just in time.

the first scsi card we tried didn’t show up on the bus, and appeared to even kill the pci slot for subsequent cards! it was probably dirty contacts, and we managed to get a second card working after some fiddling. it only had a 68-pin connector internally but not 50-pin, so brock found a cute little adapter to convert between just those two.

dumping both kinds of disks was pretty straightforward. power down the support machine just to be safe, connect a disk, lsblk, ddrescue. unfortunately the disk in the rusty IPC (serial number 134F2609) failed to spin up or even appear on the bus. one of the SS5 boxes has two disks, so maybe we can give that IPC one of those when we repair it.

% paste <(du -sB 1 *) <(sha256sum * | cut -c 1-64)
212910592       131F2926.img            49fda241d7e1cacccd1738a4401642be22665b6f9c445f0bb142123b47394062
2149761536      507FA05C.img            6527d223b41997cfba0b888de3f4c53d79242dd4b1b575a2a64e4f2e747d24c7
546079232       538F1242.bottom.img     5f3aa1b5ccc2a6069141d9f0a752e59bd508684561a047a1b6c4b3e62cc077ee
546079232       538F1242.top.img        d9131ba587bcb29b18c0230fa017d419753821f2dfeaeb56c9bb2840812aa488
4306485760      FW84450552.img          266cb20bf33f9102e587796ee071bc20ade3e2849ee3cbfa5b878f970c136a17

booting the dead SS5 (serial number 507FA05C)

previously this SS5 blew one of its tantalum caps (C0909, 15 µF, 35 V) when we tried to fire it up. nathaniel suggested that it might have been a decoupling cap, run in parallel to some actual functional circuit, so we desoldered it and the machine indeed booted! unlike the other SS5, the nvram battery seems to be dead here.

we weren’t able to boot the existing solaris install, so we tried installing solaris 9, the last version with sun4m support. the installer failed to boot due to insufficient memory, so we tried installing solaris 8 instead.

the installer for solaris 8 booted! but no matter what we tried, we couldn’t type in the console. the solaris docs say Alt+Tab can focus windows in cde, but that didn’t help here. i suspect we’re stuck until we can get mouse input working.

building a sun input converter

SPARCstations use a single 8-pin mini-din port for keyboard and mouse input. we have one keyboard (sun type 4) but no mouse, and sun mice (and keyboards) are rare and expensive, so wouldn’t it be great if we could somehow use a usb keyboard and mouse?

there are two ground pins, two 5V pins, keyboard rx, keyboard tx, and mouse tx. the data pins are all 5V serial at 1200 8N1 with negative logic, with the SPARC keyboard protocol and five-byte serial mouse protocol (aka Mouse Systems protocol).

unfortunately most sun input adapters are for using sun keyboards and mice with machines with usb or ps/2 ports, which is the exact opposite of what we want. this is wildly surprising to me in 2022, like where the fuck are people finding all these spare sun peripherals?

i had a couple of raspberry pi picos lying around, and i saw that it was possible to bang out low- or full-speed usb hosts over the gpio pins using the rp2040’s “pio” feature. the pico can also do serial, albeit at 3V3 only, so perhaps we can build around that!

code for the kind of adapter we want actually exists (USB2Sun), but due to my inability to use google effectively in the 2020s era, i kept getting results for the opposite kind of adapter before giving up in frustration and deciding to write my own. (the trick that worked, by the way, was googling “usb2sun”, by analogy with “sun2usb”.)

i dug up a pico and some usb ports from my bucket of front panel bits.

i hadn’t worked with microcontrollers before, or really done any electronics irl (this section happened before subamp), so i learned to solder for the very first time, then i spent a couple days messing around with various outputs like leds, a piezo buzzer, and a little i2c display.

i wired up an 8-pin mini-din cable, using a reversible plug that allowed both of the possible mirrored pin layouts, but despite checking and double checking it, i ended up wiring up the wrong layout. i was unable to remove enough of the solder from the side that was supposed to go into the port, so i had to buy a new plug and start over. (i later learned that this was because i had completely oxidised the soldering iron tip, by not keeping it coated in solder, and more importantly, leaving it switched on all weekend. sorry @ariashark.)

after messing around with platformio some more (including reporting a bug in the rp2040 core), i managed to get the usb host working! we can now read hid reports from a WMO and HP usb keyboard, but not a microsoft keyboard for some reason. maybe it has something to do with the usb composite device, or maybe it’s the same reasons that the keyboard is hid-microsoft on linux and not hid-generic, i’m not sure yet.

https://twitter.com/i/status/1591829743149920258

the remaining parts have since arrived, including the very important 5V/3V3 level shifter, so stay tuned!