It’s not often that we see floppy disks around nowadays, but this week proved to be an exception with a donation of a paper envelope of disks, but not just any disks.
The Troublemaker: Unistat V4.53
In this case, it was an old copy of Unistat with an Educational License V4.53 belonging to one of my PhD supervisors, contained in an envelope with the regular EULA warning on the flap …
… and a fairly extensive EULA in small text on the rear. Yikes. But we are allowed to make one copy of the software and we are allowed to transfer the software, so that’s all good it seems.
The package comes on five high-density floppy disks, with copyright date extending to 1998.
The rear of the disks are not particularly special with black-ink printing on the rear labelling area which is barely visible. The write protect tabs are all in the read/write position.
The disks come with three pages of troubleshooting tips and hints which are mostly specific to the software except for the portion above which deals with installation issues. It makes it clear that the first disk acts as a keying disk which provides copy protection requiring BIOS access to read correctly, otherwise a bypass password needs to be obtained to install. Disks must not be write protected as it seems the first install will write details back to the disk. Bad sectors are normal … or so they say. Eugh, that’s not fun, but that’s not so bad news if you have a KryoFlux!
Copying the Disks Normally
A regular user may try to copy the disk, but alas, using WinImage, we are not able to succeed as there is a read error on Track 24, Head 0. It’s also visible that Windows 10 has a habit of writing to any floppy it detects as it automounts it and writes a “System Volume Information” folder to the disk.
Luckily, I tried this experiment after I imaged the disk fully with the Kryoflux, but it’s just another reason to avoid Windows 10. It is possible to make a partial copy omitting the track, but that won’t be sufficient.
Trying the image in DOSBox, the installer freezes with the image mounted since it probably uses a BIOS direct access to the mounted drive which isn’t supported.
Of course, copying the files only results in the complaint that a bypass password is needed since the authenticity of the disk can’t be verified. That is unfortunately going to be the case, at least with emulation.
Getting the KryoFlux Going
Since my initial use of the KryoFlux, the software has been further improved with write capabilities, so I thought it would be easy to get going again. Unfortunately, having upgraded my workstation, I ran into some unexpected hurdles.
The first concerns users of Arduino, which defaults to have the “Bossa Program Port” driver take over the Kryoflux board for itself. Manually updating the driver with the supplied driver fixed this issue.
The next issue, however, wasn’t something I ended up being able to solve. Attempting to calibrate the drive resulted in errors communicating with the KryoFlux hardware. I suspected this is a permissions issue with DTC.exe being invoked by Java, but despite playing with administrative privileges, relocating the files to other folders and even using the command prompt, I was not able to resolve it. Instead, DTC just “closed” without so much as a message.
Perhaps it was related to the AMD USB controller on my Ryzen machine, as I then attempted to run the KryoFlux through a VMWare USB pass-through to a Windows 7 VM but except suffered a large number of Stream Buffering Errors due to the timing sensitivity of the I/O … so it’s time to go back to a physical machine.
KryoFlux in Action
By grabbing an older Windows 7 laptop, I had no problems getting KryoFlux 3.00 running.
The first disk already shows a lot of places where it seems the disk may have been modified since it was originally written. The disk was dumped to STREAM and an MFM image.
Inspecting Track 24 shows exactly where the protection was – 12 sectors were decoded as normal, but then it seems that there are two sectors recorded in (perhaps) double-density bitrate, with the end of the track having perhaps an FM signal? Perhaps if the track is seen to have bad sectors, the protection would “pass” the disk as genuine, but maybe it is using BIOS direct access routines to try and decode these “mixed” encoding tracks.
Disk 2 has an unusually high level of modified tracks.
Whereas all the other disks only ever showed modification on track zero, side 1.
I didn’t realise in the past but KryoFlux is capable of drawing out the STREAM data as a consistency plot which shows the times as well as whether the multiple samples are sufficiently consistent to allow for reproduction.
The current manual has quite a few examples of the consistency plot along with different copy protection schemes. In the case of my plots, this was done simply by using the following command (along with output):
>dtc -p -m1 -funistat1\* -i0 -funistat1r.img -i4 -pg2 KryoFlux DiskTool Console, v3.00_Win32, uiv.1, Apr 15 2018, 23:45:03 (c) 2009-2018 KryoFlux Products & Services Ltd. Developed by The Software Preservation Society, www.softpres.org Licensed for private, non-commercial use only. Stream file: unistat1\track 00.0 : frev: 77802, drift: 0.932 us, tfer: 371172 B/s, rpm: 299.635 00.0 : base: 1.001 us [99.762%], band: 1.998 us, 3.002 us, 4.017 us 00.0 : MFM: OK*, trk: 000, sec: 18, *H +17 00.1 : frev: 88498, drift: 0.449 us, tfer: 424713 B/s, rpm: 299.636 00.1 : base: 1.000 us [99.954%], band: 2.002 us, 2.999 us, 4.001 us 00.1 : MFM: OK*, trk: 000, sec: 18, *H +9 01.0 : frev: 79557, drift: 0.899 us, tfer: 379413 B/s, rpm: 299.635 01.0 : base: 1.000 us [99.948%], band: 1.997 us, 3.001 us, 4.001 us 01.0 : MFM: OK, trk: 001, sec: 18 01.1 : frev: 78118, drift: 0.308 us, tfer: 372580 B/s, rpm: 299.644 01.1 : base: 1.000 us [99.782%], band: 1.991 us, 3.000 us, 4.011 us 01.1 : MFM: OK, trk: 001, sec: 18 02.0 : frev: 78109, drift: 0.216 us, tfer: 371843 B/s, rpm: 299.645 02.0 : base: 1.001 us [99.800%], band: 1.994 us, 3.003 us, 4.009 us 02.0 : MFM: OK, trk: 002, sec: 18 [...] 24.0 : frev: 71326, drift: 0.941 us, tfer: 343594 B/s, rpm: 299.622 24.0 : base: 1.024 us [98.857%], band: 2.002 us, 3.071 us, 4.030 us 24.0 : MFM: OK*, trk: 024, sec: 12, *NH +1 24.1 : frev: 82494, drift: 0.425 us, tfer: 394285 B/s, rpm: 299.619 24.1 : base: 1.001 us [99.740%], band: 1.993 us, 3.004 us, 4.012 us 24.1 : MFM: OK, trk: 024, sec: 18 [...] 82.0 : MFM: <unformatted> 82.1 : frev: 8326, drift: 0.616 us, tfer: 60998 B/s, rpm: 299.612 82.1 : base: 1.964 us [61.171%], band: 3.928 us?, 8.587 us? 82.1 : MFM: <unformatted> 83.0 : frev: 12885, drift: 0.092 us, tfer: 86427 B/s, rpm: 299.612 83.0 : base: 1.896 us [60.022%], band: 2.989 us?, 5.687 us?, 8.020 us? 83.0 : MFM: <unformatted> 83.1 : frev: 8127, drift: 0.125 us, tfer: 59992 B/s, rpm: 299.615 83.1 : base: 0.998 us [33.091%], band: 1.995 us?, 2.109 us? 83.1 : MFM: <unformatted> Enjoy your shiny new disk image! Please consider helping us to preserve media and continue development: www.softpres.org/donate
As with the manual, the rule is if you can “draw” a line through the green portion below the plot, then it is possible to recreate the disk.
In the case of the unformatted/unusued tracks shown above, the consistency plot is red, as expected as it is just “noise”. The entropy analysis would detect this and attempt to recreate it as well.
Recreating the Disks & Testing Them
To write disks with the KryoFlux requires ensuring the write-gate jumper is closed to allow for writing to occur, and the use of the command line.
Not being too sophisticated, I used the bare minimum of a write command just to make a raw copy of the original based on the STREAM files. This doesn’t validate the format at all, which is probably less likely to be successful, but I thought I’d give it a try with my trusty Sony MPF920.
Believe it or not – it seems to have worked first try. Plopping the copied disks into my Techway machine with its quirky BIOS that identifies the 3.5″ drive as 5.25″, the disk reads just fine.
The setup program starts, I choose to run the typical installation …
After sitting for a short while and querying the disk, it’s happy and starts installing. Wow.
Soon enough, it asks for the second disk … I eject the copy and show it to the camera. Indeed, it is not the original disk and it’s probably a good thing since the original Disk 1 sounds a bit “scrapey” so it might well be shedding oxide.
The version of Office 97 on the machine isn’t new enough, but that’s not the fault of the disk. Installation completed successfully …
… and indeed, the software is happy to run although this was done on a physical computer because of the way the DRM works. Short of taking some time to try and crack the protection or obtain the bypass password (I doubt it would still be available), running it on an emulator may only be possible where it is first installed using a physical computer and the imaged system is then emulated.
It seems that whoever initially installed it chosen to enter pretty a “random” name/organisation which had been written to the installation disk for posterity.
Copy protection and DRM are a headache inflicted on legitimate consumers by companies looking to protect their software. Unfortunately, it also makes archival and preservation a little more difficult.
While the KryoFlux was initially impressive just for its ability to archive and understand a wide variety of floppy disk formats, it is now also capable of reproducing some of those formats including the copy protection characteristics. Given the EULA’s provision for users to make one copy – the use of DRM copy protection was definitely unkind and restrictive of that provision. Regardless, the KryoFlux has helped me save this copy of Unistat and create a copy of the original set of disks which are very much on their last legs.
Maybe when I get the time in the future, I’ll explore what Unistat can do.