Cataloging the archived Xerox PARC cartridges, overcoming password protection, work on 1401

ALTO DISK CARTRIDGE ARCHIVING

Developing record of all directory entries

I mounted and booted every cartridge image we had archived so far, issuing the ? command to list the directory of each. I did this under the Contralto simulator and took screen snapshots with that program. Each was a PNG format image file of one screen of the output.

These are all stored allowing a fairly quick scan through all the images to locate any program or file of interest (by name). A future effort might extract the file names themselves and create a quick machine searchable document.

Switching off password protection

Ken Shirriff did some investigation and determined a way to switch off password protection. It involves finding a given file, Sys.Boot, then looking at a password control field 768 bytes inside. That field contains a control flag, some SALT values and the hashed password.

Using a brute force attack, Ken recovered passwords that will unlock the six cartridges we have encountered so far that are protected. I decided to build a Python program to to this.

In order to accomplish the function, I would need to find the directory on disk, traverse its entries and locate the one for Sys.Boot. Then, with the file located, I would need to move 768 bytes into the file to capture the password control field.

The program can then store a null flag into the field and rewrite that sector to the disk image, thus switching off password protection. Alternatively the program could try a brute force attack to retrieve the password itself. 

There are complications in chasing the directory sectors, as individual directory entries can span sectors. Too, the location of the directory and of Sys.Boot varies across different disk images I have examined. I am searching for a guaranteed method that will work for all such images.

Fortunately, Ken told me of a much easier method. The first sector on the disk (track 0, head 0, sector 0) is always the first page of the Sys.Boot file. It has the first 512 bytes of that file and its label field points to the next sector of the file.

Jump to the next sector and indexing into that sector by 256 bytes will give you the password flag. It is FF FF for a protected disk. Set the flag to 00 00 and the task is done. I stripped down my Python program, gave it a Windows file open dialog box, and tested it with several protected cartridges.

IBM 1401 PROBLEM WITH READ-PRINT SEQUENCES

We spent more diagnostic time looking at the issue of false Reader Stop conditions when repeatedly reading cards and printing lines. This will fail sporadically on a job that reads and lists cards, but fails much more 'reliably' with tight code such as Read-Move-Print-Branch loops.

We discovered that the problem is a timing issue that occurs when the printer logic is transferring its data from the core memory locations 201-232 to the special internal memory buffer in the hardware. When you issue a Print command, it appears to finish rapidly, while the logic and physical printer hardware continues to print the line.

There is a 2 ms window where the logic fetches the 132 characters from main core memory and places them in the special buffer. During this 2ms, hardware will block the card reader logic from firing the reader clutch, since the card reader will also be accessing main core memory as it reads in each card.

With the sequence Read-Print-Read-Print-Read-Print-Read-Halt we usually fail on the last read. That read is delayed slightly by the printer transfer, then fires the clutch. The 1402 itself detects some problem, most likely that it thinks the Clutch didn't activate when commanded or that the clutch activated without a command from the processor.

It then raises the Stop condition which switches off the Reader Feed flipflop in the 1401, producing a characteristic very narrow clutch pulse. A number of conditions can cause the Reader Stop, although its main causes in a properly working machine are card jams or a card failing to feed from the hopper.

The system will also check its own operation by using a relay (10 - clutch check). These tests should be made only during a certain part of a feed cycle. At the enabled time, measured as a span of degrees of rotation of the reader mechanism, the clutch check relay must agree with the state of the clutch command coming from the 1401 processor.

We are looking for a case where the processor asked for a feed cycle but the reader isn't actually moving the cards forward, or the alternate case where the reader begins to move cards but the processor did not request it.

We will need to test the conditions triggering a Reader Stop to know which is the case causing our spurious stops. Is it a spurious jam, a movement thought to be uncommanded, or a failure to move after a command?

A card jam is detected if the microswitches that indicate a card is present at the hopper (card lever 1) or between check and read stations (card lever 2) don't close and open at the appropriate rotational positions in a feed cycle. Cards must clear stations and a new card show up at defined degree ranges. If this doesn't match, we probably have a jam inside.