So I was reminiscing about my old Apple II plus days and was reminded of a question that always bothered me. The question also applies to CD copying. Note to mods: I’m just asking out of curiosity – not seeking tutelage.
I’m assuming that the reason cracked copies wouldn’t work is because the copying program was accepting whatever official but purposefully inaccurate “directory” was on the disk making any copies have incomplete information. Why couldn’t crackers just write a program that would simply copied a disk bit by bit (literally)?
They did.
Unsurprisingly, they were called “bit copies.”
But, there are other ways to make it difficult to make a copied program run - for example, you could trap read errors from the CD (or floppy), and only run if you got those errors.
Optical media has a non-writable track (ATIP) that contains information about the disc itself - the manufacturer, the dye type, etc - so it’s possible for a bitwise copy to still be different from the original (and presumably, in the case of software installers) for this to be used to prevent unauthorised copies from working.
Well this certainly couldn’t have been prevalent otherwise there wouldn’t have been programs like Locksmith, Copy 2 Plus and the need for cracked versions of every software release since the beginning of time, no? I would think if this was the case then all you’d need was a copy of “Bit Slayer” and that’d be it (at least for those copy protection methods that worked by not being able to clone a disk).
Way back when, many of the programs for the commodore 64 would do “half tracking” where they would program the floppy drive to read halfway between one track and another. Even if you did a track by track, bit by bit copy, you would never correctly read the half-tracked information since the read head would never be in the correct position to read it. Eventually the hackers figured out what was going on and wrote half-tracking copying programs.
I don’t know if this type of copy protection was ever implemented on other systems.
IIRC one technique actually had a hole drilled/burned on the floppy disk - the program would attempt to write to that location, and if it took, then it wasn’t an original disk.
More sophisticated methods included a partial bit- magnetized enough to register as 1 sometimes and 0 other times. Read multiple times, look for disagreeing results. If the results agree, it’s an error. I forget which program it was the user complained it was failing, we looked at the disk, and one track was worn smooth, all the emulsion was work off in one spot. The program had been run so many times it wore out the validation check spot on the diskette.
As others point out, you can do the same trick with CD’s - put a deliberate error, and if the program reads that spot and finds the error, it’s a valid disk.
Of course, in a lot of programs, it was also easy in those days to use debug tools to track the execution of the program, determine the code segment that did the checking, and replace it with a simple routine that returned “true”. A lot of modern cracking does the same thing but the program writers try to bury and obscure their code to make that much more difficult.
Yes, all these techniques were used in the floppy days, with the idea being to make the original or key floppy immune to duplication. Bad sectors in a precise place, half-stepping or double-stepping the read heads, writing a “key” somewhere in the tracks outside normal usage, etc.
The usual method for cracking these games etc. was to find the point where the loader did a subroutine call to check disk validity, and bridge across the SUB with a string of NOP bytes. The locks got more and more sophisticated and crafty and “uncrackable” over a few years, but all could be defeated by just this two-minute hack with a byte editor. Like putting a Chubb lock on a cardboard door.
Slightly different, but I worked for a software company that sold very expensive licensed software in the 1990s, and used hard keys (dongles) to protect it. Since the customers were intermediate developers who were quite skilled (and could sell quite a few pirated systems to their customers if they defeated the licensing lock), our programmers pulled the crafty trick of not failing the lock-check if the loader checksum failed, but doing something odd like rebooting the system on the hour. When Joe C-for-Clever Pirate called up to complain that the software was misbehaving, they’d find themselves in interesting hard places when we wouldn’t sell them any more licenses to resell.
I remember some C-64 programs that would prompt you for certain words from the manual…so you had to have that available it you want the program to work.
An analogy, of course, between a regular file system copy and a bit copy is sort of like the difference between copying a book by dictating the words and sentences to someone who then writes those words and sentences into a new book versus photocopying the pages. There could be nuances that would only be caught by a photocopy, such as stray ink splotches, extra serifs or swirls on letters, changes in font size, margin differences, and perhaps even the exact number of words per page.
They did create programs that copied bit-by-bit. And, in many cases, that was enough. But the whole thing was an arms race, and eventually it became easier just to create a NoCD crack than to bother.
Plus NoCD cracks were, unlike full copies, quasi-legitimate. You could argue you were using it to make a game easier to play–not having to constantly swap out CDs for every game. So all pirate had to do was create a normal copy of the CD, throw in the NoCD crack, and no need to do anything fancy.
Anti-copy measures varied from a single “no-copy” bit which the OS and applications were expected to respect, to elaborate schemes intended to defeat bit-for-bit copy programs. The length of inter-sector gaps could be varied; a small amount of data could be placed into inter-sector gaps; as mentioned already, other techniques are possible. The protected disk was read with special software, not just the standard BIOS. Hidden data read from the disk, rather than just checked for a specific value, could be used to complete the load process, e.g. as a decryption key for software text.
When stymied by these measures, the cracker might fall back on a “Plan B” – capture memory contents of the application after it’s loaded from floppy and after its done its protection tests. But the copy-protection methods could take measures against this as well. Simplest was to check that a specially protected disk was still inserted on certain occasions, but also measures could be taken to make it hard to capture a useful snapshot of memory contents. (For example, the breakpoint interrupt vector is a memory location useful to such a cracker; the protective program might repeatedly scribble over that vector!)
I bought the kids Where in the World is Carmen Sandiego that used this. It came with a “pocket” edition of an encyclopedia and would occasionally ask for the first entry on a given page.
Yeah, I got rid of that.
At some point you’re annoying the users more than the crackers.
And again, that “lock” could be defeated in several ways - by bypassing the subroutine that called the inquiry, or by changing the lookup so it was always the same code or word.
One was defeatable if you froze your system clock (using a little TSR) and the randomizer would thus always choose the same key phrase.
Oh…I remember one of my favorite protections. There was a free-ware version of some page layout software. Everything you printed would be watermarked. But the word used for the watermark was in the registry, and if you just deleted the word (I think leaving the key itself effectively empty), the watermark was effectively invisible.