Analysis of Dungeon Master and Chaos Strikes Back Atari ST Floppy Disks (2009)(dmweb.free.fr)
dmweb.free.fr
Analysis of Dungeon Master and Chaos Strikes Back Atari ST Floppy Disks (2009)
http://dmweb.free.fr/?q=node/1429
11 comments
The pattern of misalignment is also very clever too; instead of simply putting "halfway" bits with a timing right at the boundary, it varies the bit timing over the whole window:
http://dmweb.free.fr/files/Game_Chaos.Strikes.Back_UK_Versio...
I wonder if a pattern like this would also be useful as a "jitter check" --- which bits change and the statistics of their values over many reads could show how closely aligned the drive mechanism is. A "perfect" drive would yield an average value of those bits of 0.5, with any asymmetry in the timing causing the average values to increase or decrease from that.
http://dmweb.free.fr/files/Game_Chaos.Strikes.Back_UK_Versio...
I wonder if a pattern like this would also be useful as a "jitter check" --- which bits change and the statistics of their values over many reads could show how closely aligned the drive mechanism is. A "perfect" drive would yield an average value of those bits of 0.5, with any asymmetry in the timing causing the average values to increase or decrease from that.
> I wonder if a pattern like this would also be useful as a "jitter check" --- which bits change and the statistics of their values over many reads could show how closely aligned the drive mechanism is.
Maybe this type of global synchronisation was built into the FDC? You don't need fuzzy bits to detect this, at the most basic level the PLL keeps the local stream of bitcells in sync in the current sector... the deltas (as a side effect of the sync) could be used to calculate an average and change the global expected timing of the window - as it collects more deltas it would converging on the global difference between the physical characteristics of the drive and the disc timings (i.e ultimately the difference between the drive that wrote it and the drive reading it).
If the FDC failed to read a sector due to PLL synchronisation (would that result in an invalid MFM encoding sequence?), then it could attempt to read other sectors to gather more delta samples and obtain more accurate expected timings before trying again.
Since the fuzzy bit trick still produced valid MFM sequences i suppose this type of functionality would not get the drive stuck in that case.
Maybe this type of global synchronisation was built into the FDC? You don't need fuzzy bits to detect this, at the most basic level the PLL keeps the local stream of bitcells in sync in the current sector... the deltas (as a side effect of the sync) could be used to calculate an average and change the global expected timing of the window - as it collects more deltas it would converging on the global difference between the physical characteristics of the drive and the disc timings (i.e ultimately the difference between the drive that wrote it and the drive reading it).
If the FDC failed to read a sector due to PLL synchronisation (would that result in an invalid MFM encoding sequence?), then it could attempt to read other sectors to gather more delta samples and obtain more accurate expected timings before trying again.
Since the fuzzy bit trick still produced valid MFM sequences i suppose this type of functionality would not get the drive stuck in that case.
This SORT of thing was pretty common copy protection on Ataris. "I'm told" the 1050 "dual density" disk drives had a potentiometer on it that could be adjusted to vastly speed up or slow down the drive. That, combined with software to tell "you" when, could be used to purposely mis-copy sectors to a destination floppy to replicate the effect.
The schemes I ran into as a kid used bad sectors as the proof of authenticity - literally the medium had a hole punched in it.
The copy protection was so effective, it was able thwart crackers for over a year after release. The copy protection routine didn't just run once, it constantly checks while playing the game. If you try patching one check, you will get stuck in a later part while playing the game.
Modern Vintage Gamer had a good video recently about this:
https://www.youtube.com/watch?v=VheNpiSZxf0
Modern Vintage Gamer had a good video recently about this:
https://www.youtube.com/watch?v=VheNpiSZxf0
I still have a 1541 C-64 disk drive with modified hardware that let it copy anything back in the day. Ordered it mail order, just open up the drive and plug it in. I got boxes of 'backup' games, I wonder how many floppies could be salvagible after 30 years? 1541 copy protection was so bad, the knocking would knock the drives out of alignment occasionally, and you'd have to mail them out to get repaired.
If you didn't, check the PDF document at the end of the page, it has all the explanations (almost 80 pages !). The programs the guy developed to analyze the disk protections are very cool.
OT: This reminded me of the time, I wrote a track loader system on Amiga for my trackmo/music disc. Boy this was really hard work and took me at least one book about the Amiga disc system.
This is so neat, i love this stuff. Explaining things in the context of trying to exploit part of it's behavior seems to make it more tasty :)
[deleted]
One and only time I got into d&d (well it was a dungeon and it did have a dragon) and I was hooked for several weeks. The guys who wrote it were geniuses of their time..
FWIW, I love reading about Apple II and C64 copy protection schemes.
copy protection in general is fascinating because for the most part you get to learn about the bleeding edge in technical knowledge for the era. tigress vm is pretty interesting if u want something more recent to check out
Total throwback. The good ol’ days!
"fuzzy bits". good stuff, excellent read.
To detect an original from a copy, the game was reading a particular sector several time ensuring it got different bit values for this sector at least some of the times.
Original floppy copies of the game contain these "fuzzy" sectors. As the floppy drive in consumer machine was not able to write such fuzzy sectors, an illegal copy could be spotted by the game by simply checking that every read of this supposedly fuzzy sector was yielding always the same sequence of bits (that was determined when read by the floppy drive making the illegal copy in the first place).
Now how can a sector yield different values for every read ? Some bit cells of the fuzzy sector were (purposedly) temporally mis-aligned; coupled to the micro-variations of the read speed of the floppy drive at every read, this yielded different sequence of bits on consecutive reads.