I have encountered the following copy protection methods when parsing FDS disks and disk images. Some disks, in particular the unlicensed utility programs from Takumako and those odd Magicard disks, combine several methods. The first method is already described on the wiki; I have not seen a description of the other ones there.
I have yet to encounter a disk, licensed, unlicensed or bootleg, that checks for the CRC field content being incorrect on purpose.
Hidden file(s)
Used on (not exhaustive): Yume Koujou Doki Doki Panic (FCG-DRM), Tobidase Daisakusen (SQF-TDS), Disks for the Venus Game Converter
There is/are one or more additional pair(s) of block types 3 (file header)/block types 4 (file data) beyond what is specified at the beginning of the disk in block type 2 (file count). Simple copy utilities that trust the value in block type 2 to be valid will not copy those additional files. The game will check for the presence of these files and complain if they are not found or do not possess the expected content.
Proper treatment when parsing a disk: Check for additional valid block type 3/4 pairs beyond the file count specified in block type 2.
File larger than 32768 bytes
Used on: Super Lode Runner (IFD-SLR)/II (IFD-SL2), The Monitor Puzzle: Kinetic Connection (IFD-KIN)/Vol. 2 (IFD-KI2), Mahjong Kazoku (IFD-MJK)
The main program on the first disk is in a file that is larger than 32768 bytes and so will not fit into the FDS RAM Adapter's PRG-RAM. This is good enough to foil any attempts at copying the disk without additional hardware, i.e. with just the FDS RAM Adapter and copy software. The initial boot load does not include that file. Instead, the initial boot load reads only a small stub, which contains a custom loader that skips the bytes in excess of 32768 bytes from the beginning of said file.
Proper treatment when parsing a disk: Nothing special, as the method is transparent to any hardware or software that does not require fitting the oversize file into 32 KiB of RAM.
Invalid file sizes specified in block type 3 (file header)
Used on: Graphic Editor Hokusai, Jingorou (both unlicensed utilities from Takumako), Front Fareast Magicard bootleg disks
The actual size of a file is different (larger in all observed cases) than what is specified in the "file size" field of block type 3 (file header).
The Takumako utilities specify a file size of 1 even as the actual size is $C000 in the case of Graphic Editor Hokusai and $E000 in the case of Jingorou. The files are properly read by a stub that is read during the initial boot load. Obviously, some parts of those files would be written to areas where no RAM is mapped, but that's okay. Bootleg game disks for the Front Fareast Magicard devices specify a file size of 8 even as the actual size is $8000 for CPU files and $8000/$4000/$2000 for PPU files on CNROM-256/CNROM-128/NROM games. The files are properly read by the device's own BIOS which replaces the FDS BIOS upon activation.
Proper treatment when parsing a disk: When the original CRC fields are available, by trying common file sizes other than the one specified in block type 3 (file header) until the CRC matches; this however risks misidentifying the size in the case of an accidential CRC match. Without original CRC fields available, these disks are only parsable with prior knowledge on the correct size or how to deduce it.
Heuristic for the Takumako games: When encountering a file to CPU $2000 size $0001 for the *third* time, then the actual size is $C000 bytes if that file is included in block type 2's file count (Graphic Editor Hokusai), and $E000 bytes if that file is NOT included in block type 2's file count (Jingorou). The four-letter game ID for both disks is "OUJI".
Correct method for FFE Magicard disks (taken from FFE Super Magicard BIOS): When encountering a file to CPU $4FFF size $0008, if byte $0 bit 7 is set and byte $7 !=$AA, then file sizes specified in block type 3 (file header) on all subsequent files, on all subsequent disk sides, must be ignored and substituted with $8000 for CPU files, for PPU files with $2000 if byte $1 SHR 5 is 7 (specifies NROM), with $4000 if byte $1 SHR 5 is 6 (specifies CNROM-128), and $8000 otherwise.
Block type 5
Used on: Front Fareast Magicard bootleg disks
There can be an additional block type 5 which merely contains an additional 512 bytes of "trainer" data, without an additional header. (This is where the "trainer" data on old Mapper 6/Mapper 17 iNES images comes from.)
Proper treatment when parsing a disk (taken from FFE Super Magicard BIOS): When encountering a file to CPU $4FFF size $0008, if byte $0 bit 6 is set and byte $7 ==$00, then expect block type 5 with 512 bytes of data, and a proper CRC if available, on that same disk side only following the block type 3 (file header)/block type 4 (file data) pairs expected according to block type 2 (file count).
I have yet to encounter a disk, licensed, unlicensed or bootleg, that checks for the CRC field content being incorrect on purpose.
Hidden file(s)
Used on (not exhaustive): Yume Koujou Doki Doki Panic (FCG-DRM), Tobidase Daisakusen (SQF-TDS), Disks for the Venus Game Converter
There is/are one or more additional pair(s) of block types 3 (file header)/block types 4 (file data) beyond what is specified at the beginning of the disk in block type 2 (file count). Simple copy utilities that trust the value in block type 2 to be valid will not copy those additional files. The game will check for the presence of these files and complain if they are not found or do not possess the expected content.
Proper treatment when parsing a disk: Check for additional valid block type 3/4 pairs beyond the file count specified in block type 2.
File larger than 32768 bytes
Used on: Super Lode Runner (IFD-SLR)/II (IFD-SL2), The Monitor Puzzle: Kinetic Connection (IFD-KIN)/Vol. 2 (IFD-KI2), Mahjong Kazoku (IFD-MJK)
The main program on the first disk is in a file that is larger than 32768 bytes and so will not fit into the FDS RAM Adapter's PRG-RAM. This is good enough to foil any attempts at copying the disk without additional hardware, i.e. with just the FDS RAM Adapter and copy software. The initial boot load does not include that file. Instead, the initial boot load reads only a small stub, which contains a custom loader that skips the bytes in excess of 32768 bytes from the beginning of said file.
Proper treatment when parsing a disk: Nothing special, as the method is transparent to any hardware or software that does not require fitting the oversize file into 32 KiB of RAM.
Invalid file sizes specified in block type 3 (file header)
Used on: Graphic Editor Hokusai, Jingorou (both unlicensed utilities from Takumako), Front Fareast Magicard bootleg disks
The actual size of a file is different (larger in all observed cases) than what is specified in the "file size" field of block type 3 (file header).
The Takumako utilities specify a file size of 1 even as the actual size is $C000 in the case of Graphic Editor Hokusai and $E000 in the case of Jingorou. The files are properly read by a stub that is read during the initial boot load. Obviously, some parts of those files would be written to areas where no RAM is mapped, but that's okay. Bootleg game disks for the Front Fareast Magicard devices specify a file size of 8 even as the actual size is $8000 for CPU files and $8000/$4000/$2000 for PPU files on CNROM-256/CNROM-128/NROM games. The files are properly read by the device's own BIOS which replaces the FDS BIOS upon activation.
Proper treatment when parsing a disk: When the original CRC fields are available, by trying common file sizes other than the one specified in block type 3 (file header) until the CRC matches; this however risks misidentifying the size in the case of an accidential CRC match. Without original CRC fields available, these disks are only parsable with prior knowledge on the correct size or how to deduce it.
Heuristic for the Takumako games: When encountering a file to CPU $2000 size $0001 for the *third* time, then the actual size is $C000 bytes if that file is included in block type 2's file count (Graphic Editor Hokusai), and $E000 bytes if that file is NOT included in block type 2's file count (Jingorou). The four-letter game ID for both disks is "OUJI".
Correct method for FFE Magicard disks (taken from FFE Super Magicard BIOS): When encountering a file to CPU $4FFF size $0008, if byte $0 bit 7 is set and byte $7 !=$AA, then file sizes specified in block type 3 (file header) on all subsequent files, on all subsequent disk sides, must be ignored and substituted with $8000 for CPU files, for PPU files with $2000 if byte $1 SHR 5 is 7 (specifies NROM), with $4000 if byte $1 SHR 5 is 6 (specifies CNROM-128), and $8000 otherwise.
Block type 5
Used on: Front Fareast Magicard bootleg disks
There can be an additional block type 5 which merely contains an additional 512 bytes of "trainer" data, without an additional header. (This is where the "trainer" data on old Mapper 6/Mapper 17 iNES images comes from.)
Proper treatment when parsing a disk (taken from FFE Super Magicard BIOS): When encountering a file to CPU $4FFF size $0008, if byte $0 bit 6 is set and byte $7 ==$00, then expect block type 5 with 512 bytes of data, and a proper CRC if available, on that same disk side only following the block type 3 (file header)/block type 4 (file data) pairs expected according to block type 2 (file count).