28 Dec
2009
28 Dec
'09
12:10 p.m.
Hi all --
I snagged that Vitek Systems machine that was being discussed earlier
this month and now that I'm back from my holiday travels I have some
time to play with it. It's a 68010 machine with 2mb of memory and 2
40mb scsi drives. Hooked up a terminal to TT0 and it booted up to a
login prompt, much to my amazement. The login banner says:
VITEK Nerve Center II
Copyright (c) 1992 by bioMerieux Vitek Inc.
So I guess that gives a bit more detail on what this machine is.
Clearly a system used in some sort of medical application, and
bioMerieux appears to still be in business, though I can't find any info
on this particular machine on their site.
It appears to be running an early UNIX variant called Regulus (5.2.2,
dated 7/31/86) by a company called Alcyon. I can't find much more
information on the 'net other than the fact that it existed. Anyone know
anything about this version of UNIX? Any idea what filesystem it used?
I know none of the usernames/passwords, so either a backdoor or some way
to access the filesystem would be handy...
I'm going to be dumping an image of the drives this evening, before
something catastrophic happens to them...
Thanks,
Josh
28 Dec
28 Dec
12:19 p.m.
On 12/28/09 12:10 PM, Josh Dersch wrote:
It appears to be running an early UNIX variant called
Regulus (5.2.2,
dated 7/31/86) by a company called Alcyon. I can't find much more
information on the 'net other than the fact that it existed.
It is a UNIX clone. Alcyon is also known for producing the C compiler
used in developing CP/M 68K. I'll check the CHM archives. Another listmember
sent some Alcyon software, but I've not had time to look at it.
29 Dec
29 Dec
12:35 a.m.
Al Kossow wrote:
On 12/28/09 12:10 PM, Josh Dersch wrote:
Cool, let me know if you do find anything related...
I've imaged the two drives, they're up at
http://yahozna.dyndns.org/computers/vitek. Just in the nick of time
too, drive 0 started flaking out this evening and now fails to come
ready most of the time. They're both Quantum ProDrive 40S drives.
Still no idea if it uses a standard early UNIX filesystem or not, but
I'm going to spend some time with the images and see what I can figure
out.
It's odd that a machine with hardware dated from 1990-91 is built around
a 68010/68541...
Josh
It appears to be running an early UNIX variant
called Regulus (5.2.2,
dated 7/31/86) by a company called Alcyon. I can't find much more
information on the 'net other than the fact that it existed.
It is a UNIX clone. Alcyon is also known for producing the C compiler
used in developing CP/M 68K. I'll check the CHM archives. Another
listmember
sent some Alcyon software, but I've not had time to look at it.
6:22 a.m.
Josh Dersch wrote:
I've imaged the two drives, they're up at
http://yahozna.dyndns.org/computers/vitek. Just in the nick of time
too, drive 0 started flaking out this evening and now fails to come
ready most of the time.
I've had a quick play with strings and ghex2 and I think I've come up
with the password file for that machine:
root:QvAAlS1A:0:0:/:/bin/sh
irb1::1:3:/usr/ams/r1:/bin/irbtsh
irb2::2:3:/usr/ams/r2:/bin/irbtsh
arp:1vrorYSd:11:3:/usr:/bin/sh
ams::12:3:/usr/ams:/bin/sh
bactec::13:3:/usr/bactec:/bin/sh
bacrd1::3:3:/usr/bactec:/bin/sh
ims::14:3:/usr/ims/bin:/bin/sh
vid::15:3:/usr/msd:/bin/sh
vidas1::15:3:/usr/msd/bin:/bin/sh
vidas2::15:3:/usr/msd/bin:/bin/sh
vidas3::15:3:/usr/msd/bin:/bin/sh
vidas4::15:3:/usr/msd/bin:/bin/sh
bps::20:3:/usr/bps:/bin/sh
show::94:3:/demo:/demo/bin/bsh
demo::95:3:/demo:/demo/bin/bsh
auto::99:3:/demo:/demo/bin/bsh
I'd be tempted to try logging in as 'bps' or 'demo'; that might get
you
a shell (though those accounts look like they might be disabled). As for
the root password, that's too short to be a DES hash. I don't know of
any UNIX system that stored passwords unencrypted in /etc/passwd, nor
can I find any evidence of a password hashing algorithm that produced an
8-byte base64 hash.
There's also some evidence of a "password recovery" mode in the disk0
image. How to get into that mode is not explained...
They're both Quantum ProDrive 40S drives.
Interestingly the two disc images carry the text "Miniscribe 8051p" and
"Miniscribe 8051d" in the first few bytes. I wonder if the machine
originally came with drives of that type, which were later 'dd' copied
from one to the other.
Hmm...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
7:26 a.m.
On 12/29/09 6:22 AM, Philip Pemberton wrote:
I've had a quick play with strings and ghex2 and I think I've come up
with the password file for that machine:
root:QvAAlS1A:0:0:/:/bin/sh
go in with a hex editor, and change it to
root::0:0:/:/bin/sh<nul>
preferably on a cloned image.
11:06 a.m.
Philip Pemberton wrote:
Josh Dersch wrote:
"bps" does work;
embarrassingly enough the terminal that came with the
Vitek system (A Tektronix 4205, fun!) is affixed with a label that says
"login: bps." I just hadn't taken the time to unpack the terminal until
late last night (well, early this morning). Silly me :).
Definitely an odd hash for the root password, if I can figure out how to
start the machine in single-user mode it'd be trivial to reset it,
otherwise I'll probably do as Al suggested and hack the disk image.
Maybe if I reset the machine without syncing the disks, fsck will fail
on the next boot and drop me into single user mode ;). (Gotta love the
reliability of old UNIX filesystems...)
Now I just need to find a compatible drive to replace the dying one...
I've imaged the two drives, they're up at
http://yahozna.dyndns.org/computers/vitek. Just in the nick of time
too, drive 0 started flaking out this evening and now fails to come
ready most of the time.
I've had a quick play with strings and ghex2 and I think I've come up
with the password file for that machine:
root:QvAAlS1A:0:0:/:/bin/sh
irb1::1:3:/usr/ams/r1:/bin/irbtsh
irb2::2:3:/usr/ams/r2:/bin/irbtsh
arp:1vrorYSd:11:3:/usr:/bin/sh
ams::12:3:/usr/ams:/bin/sh
bactec::13:3:/usr/bactec:/bin/sh
bacrd1::3:3:/usr/bactec:/bin/sh
ims::14:3:/usr/ims/bin:/bin/sh
vid::15:3:/usr/msd:/bin/sh
vidas1::15:3:/usr/msd/bin:/bin/sh
vidas2::15:3:/usr/msd/bin:/bin/sh
vidas3::15:3:/usr/msd/bin:/bin/sh
vidas4::15:3:/usr/msd/bin:/bin/sh
bps::20:3:/usr/bps:/bin/sh
show::94:3:/demo:/demo/bin/bsh
demo::95:3:/demo:/demo/bin/bsh
auto::99:3:/demo:/demo/bin/bsh
I'd be tempted to try logging in as 'bps' or 'demo'; that might get
you a shell (though those accounts look like they might be disabled).
As for the root password, that's too short to be a DES hash. I don't
know of any UNIX system that stored passwords unencrypted in
/etc/passwd, nor can I find any evidence of a password hashing
algorithm that produced an 8-byte base64 hash.
There's also some evidence of a "password recovery" mode in the disk0
image. How to get into that mode is not explained...
Seems fairly likely. Either that or Regulus' disklabel tool only knows
about/supports a small subset of known drives (much like my 3B2, which
is no end of fun finding compatible drives for...)
Thanks,
Josh
They're both Quantum ProDrive 40S drives.
Interestingly the two disc images carry the text "Miniscribe 8051p"
and "Miniscribe 8051d" in the first few bytes. I wonder if the machine
originally came with drives of that type, which were later 'dd' copied
from one to the other. 
11:51 a.m.
> root:QvAAlS1A:0:0:/:/bin/sh
Definitely an odd hash for the root password, if I can
figure out how
to start the machine in single-user mode it'd be trivial to reset it,
otherwise I'll probably do as Al suggested and hack the disk image.
Maybe if I reset the machine without syncing the disks, fsck will
fail on the next boot and drop me into single user mode ;). (Gotta
love the reliability of old UNIX filesystems...)
Original Bell unix stored unencrypted passwords. The first hashed
password storage used the M-209 rotor machine emulation which already
existed in unix somewhere. As with the DES hash which came shortly
after, the M-209 setup used the password as the key and encrypted a
fixed data pattern. I don't know if the M-209 variant salted. Last I
checked, the DES version used a block of zeros as the data, dunno yet
about M-209.
Haven't gotten as far as tuhs to see if I can find the old crypt yet.
De
2:20 p.m.
Dennis Boone wrote:
Original Bell unix stored unencrypted passwords. The
first hashed
password storage used the M-209 rotor machine emulation which already
existed in unix somewhere. As with the DES hash which came shortly
after, the M-209 setup used the password as the key and encrypted a
fixed data pattern. I don't know if the M-209 variant salted.
IIRC it didn't.
This would explain why John The Ripper spat out the hash as invalid...
Last I
checked, the DES version used a block of zeros as the data, dunno yet
about M-209.
I haven't managed to find a C implementation of the M209 cipher.
Apparently DES was introduced around 1976, so anything older than that
should include an implementation.
I've raided Google Code Search and TUHS and come up with...
--- DES algorithm, in C ---
the source to crypt(3) from 7th Edition Unix:
http://google.com/codesearch/p#118goTAkg2o/usr/src/libc/gen/crypt.c
And passwd.c from the same:
http://google.com/codesearch/p#miRTe8ZyR0o/Archive/PDP-11/Distributions/res…
--- M209 rotor algorithm? ---
This is passwd from V6:
http://google.com/codesearch/p#miRTe8ZyR0o/Archive/PDP-11/Distributions/res…
And the password encoding function, in PDP11 assembler by the looks of
things:
http://google.com/codesearch/p#miRTe8ZyR0o/Archive/PDP-11/Distributions/res…
Any PDP11 experts want to convert that into C?
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
3:04 p.m.
> fixed data pattern. I don't know if the
M-209 variant salted.
IIRC it didn't.
Having wasted (spent?) much of the afternoon toying with this, no, it
did not.
> Last I
> checked, the DES version used a block of zeros as the data, dunno yet
> about M-209.
The crypt(3) code appears to allocate a bss block, so I'm going with the
block of zeros as likely.
I haven't managed to find a C implementation of
the M209 cipher.
Apparently DES was introduced around 1976, so anything older than that
should include an implementation.
V6 includes a crypt(1) implementation of the M209 in C, source is on
TUHS. It's not yet clear to me yet how the crypt(3) assembler
implementation translated the binary output of the (very similar
looking) algorithm to printable text. I'm still staring at the
assembler code. Evidently I don't speak PDP-11 very well today.
De
3:48 p.m.
It's not yet clear to me yet how the crypt(3)
assembler implementation
translated the binary output of the (very similar looking) algorithm to
printable text. I'm still staring at the assembler code. Evidently I
don't speak PDP-11 very well today.
Ok, finally got my lame brain to work.
After doing the rotor-cage-link crap, the password crypter takes
modulus-62 of each byte of the cryptext and base-62 encodes that
remainder using the set 0-9A-Za-z.
If I'm ambitious (hah!) tonight, maybe I'll see about hacking that into
the crypt(1) implementation and testing it.
De
4:17 p.m.
Dennis Boone wrote:
If I'm ambitious (hah!) tonight, maybe I'll
see about hacking that into
the crypt(1) implementation and testing it.
I'm trying to reimplement the PDP11 version of crypt(1) in C. Given that
until ~30 minutes ago I didn't know a single thing about the PDP11 other
than "it's big, heavy, and goes in an equipment rack", it might take a
while.
I've already un-learned everything I learned about x86 assembler. Thank
$DEITY, I've been trying to purge that from my brain for YEARS.... :)
And the more of this mess I convert, the more I want to buy a PDP11 (or
build a clone) and play... 8^O
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
5252
days inactive
5254
days old
10 comments
4 participants
participants (4)
-
aek＠bitsavers.org -
classiccmp＠philpem.me.uk -
derschjo＠mail.msu.edu -
drb＠msu.edu