> Isn't it unreadable to the game as well?Yes, but there is no data on the deliberately bad sector that the game really needs - it just reads it to see if it can (and if it gets data back but no error it will assume it is a pirated copy on a "clean" disk. The bad sector has to be part of a particular file too, so you can't just corrupt track-60-sectors-2-through-4 without also making sure "checkf.ile" is using those sectors (not a given if you do a file based copy instead of a full volume copy) or doctoring the disk will corrupt data that the game does need.
As well as being a test, if the deliberately bad block/track is not at the end of the media it would defeat the simplest copying techniques (simply copying the disk) as most basic disk copy utilities would stop at the bad block.
Other ways to defeat naive copying exist too that don't need tweaks to the physical media, which were often used in conjunction with the physical method. Examples include having a "corrupt" directory entry that referred to itself or a file with an apparent size larger than the disk, both of which would breaking simple file based full disk copying and allow the game to test its environment - if it doesn't see the deliberately bad directory entries it knows the disk is not an original. Depending on the target system other filestytem tricks are possible like bad file allocation table entries on FAT12 formatted disks. You needed to be careful to not do anything that the OS would throw up as an error or try to fix (keeping the disk read-only protects this to an extent) but the OS was fairly dim back then so that wasn't a big issue.
None of these "soft" methods would stop anyone who knew what they were doing of course, but they would block the man-on-the-street from simply being able to copy that floppy with "COPY A:. B:" or "XCOPY A:. B: /S/E" or equivalents.