I found a terminal program that will run on my Windows 98 laptop that also happens to have a simple macro language included. I believe it will be just powerful enough to allow me to script out a brute force password cracking routine. This is going to be easier than the method I was trying earlier from Linux, I think, and would probably be easier than trying to script my own method in Linux as well.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Any way to bypass a password login in CompuPro Concurrent DOS?
- Thread starter jmetal88
- Start date
Agent Orange
Veteran Member
You say brute force; what kind of routine do you have in mind?
Regarding the user name/password system set up by CompuPro for CDOS - user names and passwords are a maximum of 8 characters, with no spaces or punctuation characters permitted.
Trying every possible character combination from 1 to 8 characters in both the user name and password fields. I'm having it increment the ASCII code and skip over special characters so it's just putting out alphanumeric characters. I'm keeping track of each "place" separately and concatenating it into a string before sending it out to the serial port.
The Linux routine I had tried out before required a password dictionary, which is great if you have a list of likely candidates, but a list of every possible candidate for this would make a dictionary larger than my hard drive. So I like this better because A) I don't have to learn about interfacing the serial port directly and B) I can procedurally generate the usernames and passwords according to my own algorithm without actually saving anything to my hard disk.
Man, this is gonna take ages, though... I guess I'll leave it on for a while to see how fast it makes progress but if I don't stumble upon a working combination fairly early I may give up on this, too.
Yeah, it's not even halfway through testing the password combinations for the first user name as of this morning. This could potentially take years to crack this way.
Maybe I should try a few common user names first before going down a generated list like this. I've already tried manually guessing a few combinations, but maybe the user name will be easier to guess than the password.
Seems to me that getting an image off the hard drive and disassembling the boot loader is the most efficient way to approach this. It's one thing to brute force a password for a known user, quite another to brute force both.
Heck you'd probably be better off disassembling the boot ROM, and replacing that. Since the ROM can read the hard drive, taking that out, augmenting it with even a simple monitor can probably get you a hex dump of the disk. Or augment it with a simple serial loader so you can upload a more robust tool set. Heck, upload a Forth and you'll be down right dangerous. Everything can be done via cut and paste on the host.
Heck you'd probably be better off disassembling the boot ROM, and replacing that. Since the ROM can read the hard drive, taking that out, augmenting it with even a simple monitor can probably get you a hex dump of the disk. Or augment it with a simple serial loader so you can upload a more robust tool set. Heck, upload a Forth and you'll be down right dangerous. Everything can be done via cut and paste on the host.
So, definitely have given up on the brute force idea by now. Maybe I'll try again later if I have no luck getting into the machine by other methods.
I'm going to attempt to read the hard drive on a PC using an ISA MFM controller. I did some digging and I believe the controller I have supports this drive's geometry, so long as I can set the geometry in my PC's BIOS (the card's own BIOS would not be able to support it). I am thinking I'll try to get a Linux machine set up to image the drive since I will probably not be able to read the file system. That would also give me the ability to set the drive's geometry as a boot parameter in case I can't get it set properly in the system BIOS.
I'm going to attempt to read the hard drive on a PC using an ISA MFM controller. I did some digging and I believe the controller I have supports this drive's geometry, so long as I can set the geometry in my PC's BIOS (the card's own BIOS would not be able to support it). I am thinking I'll try to get a Linux machine set up to image the drive since I will probably not be able to read the file system. That would also give me the ability to set the drive's geometry as a boot parameter in case I can't get it set properly in the system BIOS.
Al Kossow
Documentation Wizard
buy a gesswein mfm emulator board, dump the raw flux transitions.
https://www.pdp8.net/mfm/mfm.shtml
if it isn't a known format, dave will help you interpret it
looking at the picture of the disk controller board, no commodity lsi-based PC controller is going to read it
don't waste your time. I've read literally hundreds of different format MFM drives with dave's controller
https://www.pdp8.net/mfm/mfm.shtml
if it isn't a known format, dave will help you interpret it
looking at the picture of the disk controller board, no commodity lsi-based PC controller is going to read it
don't waste your time. I've read literally hundreds of different format MFM drives with dave's controller
My PC controller is a WD1002S-WX2.
I'm not sure what pictures you were looking at, but the 816/10 uses a different board than the S100 versions of the computer do. I can look at it tonight and see if I can determine what controller chip it uses if that will help determine whether the effort is worthwhile (it is an integrated MFM/Floppy/SCSI controller board).
I don't think it has a controller chip, I think it is using whatever firmware it runs on the 8085 as a controller.
Okay, finally got a Linux setup talking to the MFM controller and the MFM controller talking to the drive. Result: When I try to DD the drive I get an I/O error.
So I guess I will have to get that emulator board if I want to read this without cracking the password. But I'd hate never knowing for sure whether I could read it with something I already have.
Your observation that the drive controller in the 10+ is designed around an 8085 is consistent with it being of the same design as the one CompuPro used for its S100 based MFM drive controller. The low level format CompuPro created for its MFM hard drives will not be readable by any PC-based MFM drive controller.
It's really unfortunate no one seems to have a boot disk for the 10+ they could provide you with. Buying yet more hardware to image the drive, figuring out where the password file is located in that image, and decrypting the password file (even if the encryption is likely not very sophisticated) is a lot of work to get this thing up and running again.
Well, I think hooking the drive up to my PC was a bad idea as it will no longer boot on the CompuPro. I never issued any write commands to the controller (only read and seek) so I'm not sure what happened, but I think it's possible my controller tried to overwrite the partition table on its own, as now that the drive won't boot I can suddenly read 8k off the beginning of the drive on the PC (it looks like garbage when I look at it, but before, when the CompuPro was booting, I wasn't able to read anything off the drive using the PC).
So I think it'd be pointless to order that MFM emulator at this point -- I think getting the proper boot disks is the only way I can save this computer.
So I think it'd be pointless to order that MFM emulator at this point -- I think getting the proper boot disks is the only way I can save this computer.
Indeed, that is likely what happened. CompuPro's MFM controller reserves the first physical sector of the drive to store data identifying it as a CompuPro formatted drive formatted with that particular controller, and to store the drive parameters. If that gets wiped out, CompuPro's drive controller will not recognize the drive.
Have you tried booting the 10+ with the boot disk you created earlier, but without the hard drive plugged in, to see what happens?
That behavior is terrible, and the developers who wrote that code should be strung up.
I had something similar happen at my last job with a firmware update on some IBM servers being used as GPFS shared file system disk servers. It turned out that on our test system, we had partitioned the RAID storage with a GPT table (primary and secondary) for testing before we got the GPFS software installed. Later when GPFS took ownership of the disk it wiped only the GPT primary table with its own data. The firmware update, at the next boot, helpfully detected the secondary GPT table at the end of the RAID and proceeded to copy it to the start of the RAID, destroying the GPFS file system. Needless to say, we weren't happy at all, as if that same sequence of events had happened on the production system, we could have lost part of a 10 PB (yes, petabytes) file system in an instant. IBM had to rush out a change to GPFS to make it exist with GPT partitioning properly.
If I try without the drive connected at all I get a "Drive 0 Not Ready" error and the machine refuses to even look at the floppy. If it sees the hard drive but has a read error, it then goes on to look at the floppy drive and attempt to boot. Previously I was inducing the read error by yanking out the smaller MFM cable connector, but now that the first sector of the drive is messed up I get the read error even with both connected, so it always attempts to boot from floppy now.
I took a look at the disk image I'm using again and compared it to some older CompuPro images and I believe the boot sector is intact, so I think there is either some software incompatibility or there is something wrong with my hardware that prevents it from finishing a boot off floppy, but not a boot off the hard drive. From what I can tell, the code that is being executed when the system boots is the code in the first 4K of the floppy image (this would all be on Track 0 if I have the geometry right). I think it is then supposed to proceed to run the loader program that is stored on the disk around the 10k mark (which I think is the beginning of Track 2), but something is preventing it from moving the heads to load the new code after the Track 0 code executes. I don't know if, perhaps, the floppy loader is making some sort of ROM call to perform that function and my ROM doesn't have those routines in the correct locations or what.
Well, just in case it gives anyone any clues, I pulled the ROM chips off the disk controller and the main board and read them using an EPROM reader. I've tried looking at a disassembly of the files, but I'm not well versed enough in any variants of assembly (aside from PIC microcontrollers) to really make anything out of it. Not that I really expect anyone here to go to that much effort to help solve my problem, but who knows, maybe one of you will be bored enough to give it a shot, haha.
FWIW the processor on the disk controller is an Intel 8085 and the processor on the main system board is an NEC V20.
There are also four Z80 processors across two other expansion cards, but I don't have any reason to believe they are involved in the boot process.
View attachment MP4Roms.zip
FWIW the processor on the disk controller is an Intel 8085 and the processor on the main system board is an NEC V20.
There are also four Z80 processors across two other expansion cards, but I don't have any reason to believe they are involved in the boot process.
View attachment MP4Roms.zip