Copy protection methods on FDS disks

[NewRisingSun]

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 Magic Card 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 Magic Card 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 Magic Card 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 Magic Card disks (taken from FFE Super Magic Card 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 Magic Card 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 Magic Card 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).

[TakuikaNinja]

I forgot I had read this post while researching FDS copy protection measures and was becoming quite confused/concerned as to where I had gotten the claim regarding Hokusai from. It doesn't seem to appear in this Japanese documentation by Enri: http://cmpslv3.stars.ne.jp/Famic/Famdis.htm

Note that puNES appears to correctly handle these protected disks as of its interim versions, aside from the FFE one which requires extra hardware. I've previously had to help fix the handling for Kosodate Gokko: https://github.com/punesemu/puNES/issues/396

There's also the case of cartridges dumped to disk using I2's Souseiki Fammy and the ROM-QD disk. The hardware maps extra PRG-RAM to $5000-$5FFF by default and has a write-only register at $4C00 which handles the memory layout of the FDS, the inserted cartridge, and its own memory. It's handled in a manner which allows for dumps to work without modifying the PRG-ROM data. Disks created using this will not work on a regular FDS as a result, and the documentation included with the product makes this very clear.

[TakuikaNinja]

Regarding Kosodate Gokko: It stores its main program without a file block indicator and loads it using the BIOS IRQ handler. (data is prefixed with a $12 byte) A Tron-like minigame becomes the only thing accessible if the main program is missing.

There are apparently two versions of this software (mentioned in Japanese here and here) - the later version supposedly makes it harder for Disk Hacker to copy it? I've found this page which claims the number of logo flashes after loading distinguishes the version - I should check which version is the one documented on no-intro.
Edit: The Japanese Wikipedia article lists 3 software versions (distinguished by packaging & disk colour) and a hardware copier version.

[TakuikaNinja]

And for completeness:

• Quick Hunter utilises low-level disk access routines to load a file block type of 0 containing its encrypted main program (data is XORed with $C9). The CRC value of the file block is still checked.
• Disk Hacker prevents copying Hacker International's own software by refusing to load disks with a licensee code of 0 in the disk info block ("Error FF"). Later software from the same company also employed a similar oversized file strategy as licensed software and stores a 44KiB file to exhaust all possible memory on the system (system RAM + PPU VRAM + RAM adapter WRAM).