CDRDAO Fork That Can Burn PSX Games Containing EDC-Based Anti-Piracy Detection Correctly(Changes Now In Official CDRDAO)

[alexfree]

https://alex-free.github.io/cdrdao/
https://github.com/alex-free/cdrdao/tree/dev

CDRDAO is a portable open source CD ripping and burning program. My fork of CDRDAO described on this page fixes a fatal bug which prevented some PSX disc images which contain an additional (EDC-based) anti-piracy measure from being burned correctly by CDRDAO.
Burning With The Generic-MMC Driver

For almost all PSX CD images (which do not contain an additional EDC-based anti-piracy measure), you have always been able to use one of the following commands below to burn a correct PSX CD-R disc with the official CDRDAO:

cdrdao write --speed 1 --driver generic-mmc --eject yourgamerip.cue

If using the above command results in a CD-R which has audio tracks containing loud static noise instead of the exepected, correct CD audio playback you need to byteswap the CD audio tracks while burning (by providing the --swap argument), with this alternative command below:

cdrdao write --speed 1 --driver generic-mmc --swap --eject yourgamerip.cue

The --swap argument is only required for some CD images that you want to burn, but not all.

You must first cd into the directory of the CD image rip before you run cdrdao, so that the .cue file of the rip is in the current directory

The generic-mmc driver (like almost every other CD burning program by default as well) corrects any incorrect EDC data it finds inside the CD image used while burning. This is actually a feature, and usually what you want. Unless you run into i.e. a PSX game which abuses this fact to provide an additional anti-piracy copy protection measure.

Introducing EDC-based additional anti-piracy copy protection found in some later PSX games. If you burn a CD image of a game which contains this EDC-based additional anti-piracy copy protection with the generic-mmc driver, CDRDAO (just like most other CD burning programs by default) will actually ‘correct’ incorrect EDC data it finds (which has been intentionally placed in various sector(s) of the original CD-ROM from which the CD image was originally ripped from). This changes what data the game itself reads from a specific part of the disc during a specific time/check function. If the game’s code itself doesn’t read the expected ‘incorrect’ EDC data, it knows that this disc is a copy and will lock up.

The good news is, there is a way around this. Some CD burning programs provide an option to not ‘update/correct’ EDC data as the CD image is burned to a CD-R. CDRDAO provides the generic-mmc-raw driver, which does offer this functionality. The problem is, since seemingly the inception of the generic-mmc-raw driver, the --swap argument does not work in combination with the generic-mmc-raw driver specifically due to a bug. This prevents you from burning a CD-R which both doesn’t update any EDC data, and has the correct byteorder for the CD audio tracks. CD images that do not require the --swap argument work as expected when burned by the generic-mmc-raw driver, but it is currently impossible to correctly burn CD images that do require the --swap argument with the generic-mmc-raw driver in the official CDRDAO.

I have finally tracked down this previously unknown bug, and provided a fix that I am trying to get into the official CDRDAO. For now, I have created my own fork which provides the bug fix enabling the --swap argument with the generic-mmc-raw driver correctly.
Burning With The Generic-MMC-Raw Driver

So for almost any PSX game CD image (including those which contain additional EDC-based copy protection), you can use one of the below CDRDAO commands to correctly burn them:

cdrdao write --speed 1 --driver generic-mmc-raw --eject yourgamerip.cue

If using the above command results in a CD-R which has audio tracks containing loud static noise instead of the exepected, correct CD audio playback you need to byteswap the CD audio tracks while burning (by providing the --swap argument), with this alternative command below:

cdrdao write --speed 1 --driver generic-mmc-raw --swap --eject yourgamerip.cue

The --swap argument is only required for some CD images that you want to burn, but not all.

[nocash]

I wasn't aware of that problems, and I am not really into disc burning, but that stuff brings up some generic questions.

Why needing --swap?
Normally, one should have disc images with correct byte order, and the software should then burn or emulate an intact disc.
So what is the --swap for... is that required to fix improperly dumped disc images? Or is it only required to overcome cdrdao-specific software bugs?

I know that cdrdao's TOC/BIN format wants BIN files in big-endian, whilst normal CUE/BIN should be little-endian (unless the audio files are marked as MOTOTOLA or MOTOROLA or whatever, but I've never seen that in practice).

EDC protection and emulation
Are those wrong EDCs on FORM1 and/or FORM2 sectors? FORM2 would be easy to emulate (just read the bytes as usually). FORM1 would require to emulate read-errors upon incorrect EDCs (I don't have that emulated in no$psx).

EDC protected titles
Do you know if there are more such titles? Additionally to the two examples mentioned on your webpage:
- Dance Dance Revolution 2nd Remix Japan Burn (Raw + Swap)
- DarkStalkers USA Burn (Raw + Swap)

EDC auto-correction and Disc creation/testing
That EDC (and ECC) auto-correction comes in nasty when developing homebrew disc-images (if a CDR is working on real hardware due to silently fixing such errors then people get fooled into thinking that they have created an intact disc image).

[alexfree]

I wasn't aware of that problems, and I am not really into disc burning, but that stuff brings up some generic questions.

Why needing --swap?
Normally, one should have disc images with correct byte order, and the software should then burn or emulate an intact disc.
So what is the --swap for... is that required to fix improperly dumped disc images? Or is it only required to overcome cdrdao-specific software bugs?

I know that cdrdao's TOC/BIN format wants BIN files in big-endian, whilst normal CUE/BIN should be little-endian (unless the audio files are marked as MOTOTOLA or MOTOROLA or whatever, but I've never seen that in practice).

EDC protection and emulation
Are those wrong EDCs on FORM1 and/or FORM2 sectors? FORM2 would be easy to emulate (just read the bytes as usually). FORM1 would require to emulate read-errors upon incorrect EDCs (I don't have that emulated in no$psx).

EDC protected titles
Do you know if there are more such titles? Additionally to the two examples mentioned on your webpage:
- Dance Dance Revolution 2nd Remix Japan Burn (Raw + Swap)
- DarkStalkers USA Burn (Raw + Swap)

EDC auto-correction and Disc creation/testing
That EDC (and ECC) auto-correction comes in nasty when developing homebrew disc-images (if a CDR is working on real hardware due to silently fixing such errors then people get fooled into thinking that they have created an intact disc image).

1) So for any redump verified disc image containing CD Audio tracks in my testing requires the --swap argument to be burned in the correct byte order. Confusingly, cdrdao is actually byteswapping by default internally when ran on Linux x86_64. By providing the --swap argument, the internal byteswapping is effectively disabled for CD audio tracks. I am not really sure why it's the default to byteswap internally. I do know that cdrdao can byteswap cd audio files as it is ripping a real CD as well with an optional argument, enabling either byteorder (although one of those byteorders is incorrect). The generic-mmc and generic-mmc-raw drivers both also take little endian samples internally in cdrdao. You do make a good point that properly ripped images should just work without needing such an argument. Maybe it would make sense to reverse the behavior in my cdrdao fork. Or even better, make it automatic by using the Motorola marker thing? Seems much better.

2) The EDC protection, at least how I've seen it, works like this. A 'reserved sector' (usually sector 12 IIRC) on a CD-ROM is pressed with all 0x00 bytes, including where the EDC checksum usually is (not all games also zero out the actual EDC checksum, but some do even though they don't have this protection type). When someone rips such a CD-ROM, sector 12 is ripped accurately. But then when you burn this rip, most CD burning software autogenerates EDC data during the burn and on the actual burned disc sector 12 will have the 'correct' EDC checksum in that case. There is a really great discussion I had with socram8888 and others on this protection in this tonyhax issue: https://github.com/socram8888/tonyhax/issues/121 . I belive duckstation will reproduce the 'game locks up' behavior on EDC-protected games if you modify the disc image to include the EDC checksum at the checked sectors.

3) I have a work in progress list on the tonyhax international readme/website (https://alex-free.github.io/tonyhax-int ... some-games) of games which contain this protection. Also, please note that DarkStalkers does not have this protection, I was just showing in that picture that all proper game rips now work (including games which don't include the protection) with the generic-mmc-raw driver in my fork.

4) Ironically, my various patcher programs that deal with psx CD images abuses the fact that the EDC data is re generated when burning. If you burn a disc image that has been patched by one of my patchers (https://alex-free.github.io/ps1demoswap or https://alex-free.github.io/aprip) using the generic-mmc-raw driver it most likely won't work because the EDC will think the patches done to the CD image are actually corrupted data and will 'fix/undo' the changes the patcher programs have made. So for now, you have to use the generic-mmc driver to burn such patched games due to the limitations my patcher programs currently possess.

[alexfree]

Interesting, I think I figured out a 'solution' to automating the --swap argument.

I think the whole reason it is needed, is because cdrdao was built with .TOC files in mind, and not *.cue files. So it treats .toc like .cue (where it expects the need to byteswap cd audio files, which is why it does it by default on i.e. Linux x86_64 little-endian). However, I think this can be better defined. I have some expiermental, non-public cdrdao modifications that seem to solve the whole --swap kludge. If you give cdrdao a .cue file, it internally 'converts' it to .toc for burning. I can identify the code doing this, and have it set a flag saying hey, this was originally a .cue file that does not contain the MOTOROLA thing in the .cue file sheet so don't treat it like a .toc file when it comes to byteswapping CD audio.

Need some testing, but thanks for pointing me in the right direction no cash. If this works, --swap will become automatic and no longer be required to be explicitly set.

[nocash]

Thanks fr the info. Sector 12 is (usually) FORM2, so the disc controller won't generate read errors if the EDC is wrong (=no need to emulate such read errors).

My first thought was that changing the cdrdao command line syntax would create chaos... but I guess nobody is seriously using CUE with big-endian BIN files, so there should be no harmful effects when ignoring the --swap option for CUE files:
If it's a CUE file, always use little-endian, no matter if --swap is specified or not.

I don't know if MOTOROLA is the exact counterpart to --swap. Official docs are just describing it as "Mutorola binary file", inofficial docs are mentioning that it's endianness-related (without saying if it's 16bit or 32bit endianness), older docs say that the keyword is to be (mis-)spelled MOTOTOLA, it does probably affect endiannes of Audio sectors (but I don't know if it's also affecting Data sectors). Or it might refer to the ancient ASCII-based Motorola S-Record format.
If you want to support that format then you might need to create a CUE file with MOTOROLA data+audio tracks, burn it with official CDRWIN sofrware, and then reverse-engineer what was written to the disc.

[alexfree]

Thanks fr the info. Sector 12 is (usually) FORM2, so the disc controller won't generate read errors if the EDC is wrong (=no need to emulate such read errors).

My first thought was that changing the cdrdao command line syntax would create chaos... but I guess nobody is seriously using CUE with big-endian BIN files, so there should be no harmful effects when ignoring the --swap option for CUE files:
If it's a CUE file, always use little-endian, no matter if --swap is specified or not.

I don't know if MOTOROLA is the exact counterpart to --swap. Official docs are just describing it as "Mutorola binary file", inofficial docs are mentioning that it's endianness-related (without saying if it's 16bit or 32bit endianness), older docs say that the keyword is to be (mis-)spelled MOTOTOLA, it does probably affect endiannes of Audio sectors (but I don't know if it's also affecting Data sectors). Or it might refer to the ancient ASCII-based Motorola S-Record format.
If you want to support that format then you might need to create a CUE file with MOTOROLA data+audio tracks, burn it with official CDRWIN sofrware, and then reverse-engineer what was written to the disc.

I've decided to just leave it the way it is in my fork. The reasoning is correct though. The --swap argument is required for proper cue files (such as redump) with little-endian audio tracks because internally cdrdao processes a cue file like a .toc file, which has big endian audio tracks.

Something really interesting though about the .toc format, is that you can rip a disc with RAW96DA0 mode (complete subchannel data) and then burn it with RAW96DA0 using just the .toc and .bin file of the rip. I don't have an actual libcrypt disc to try this with, but at least a normal game seems to work accurately with this.

So I would think, maybe one could create a converter that takes a .cue file with a .bin and .sub file of a libcrypt game and merges it all into a .toc and .bin for cdrdao. Any info on how the .sub files are laid out?

[nocash]

Yes, psxpsx has specs on cdrom image formats:
http://problemkaputt.de/psxspx-cdrom-drive.htm

Observe that there are two 96-byte formats:
.SUB has 8x12 bytes, http://problemkaputt.de/psxspx-cdrom-di ... lonecd.htm
.MDF has 8x96 bits, http://problemkaputt.de/psxspx-cdrom-di ... ol-120.htm
They are both containing the same data, but differently arranged. That's often described as "interleaved", but it's somewhat point of view which is "normal" and which is "interleaved" (I think the MDF ordering is closer to physical discs, and SUB ordering is closer to human logic).

CDRDAO does support two 96-byte formats, in the .TOC files they are called RW and RW_RAW.
They do probably correspond to the SUB and MDF formats, the problem is that I don't know which is which.

I did have (and still have) that problem about what is "RW" and what is "RW_RAW" with compressed CHD files:

CHD is just adopting the format/names RW and RW_RAW from CDRDAO's TOC files.
CDRDAO has apparently adopted the format/names RW and RW_RAW from SCSI, ATAPI, or ASPI drivers.

CHD defines RW and RW_RAW as so:

Code: Select all

  "RW"         normal "cooked" 96 bytes per sector
  "RW_RAW"     raw uninterleaved 96 bytes per sector

CDRDAO defines RW and RW_RAW as so:

Code: Select all

  RW: packed R-W sub-channel data (96 bytes, L-EC data will be generated if required),
  RW_RAW: raw R-W sub-channel data (interleaved and L-EC data already calculated, 96 bytes).

That, hmmm, going by that definitions, the terms "uninterleaved" and "interleaved" are both referring to RW_RAW, that is perfectly unclear - help!

It would be very interesting if you could make a TOC/BIN image with subchannel data - and confirm that the image is actually working when burning it with CDRDAO.

Btw. see also:
Subchannel format summary, http://problemkaputt.de/psxspx-cdrom-su ... images.htm

[nocash]

PS. Easier way to figure out what RW and RW_RAW are:
Can you dump a CDROM or Audio disc with CDRDAO in TOC/BIN format, with subchannel data?
And post a hexdump of the first sector's subchannel data (it should occur at BIN file offset 930h..98Fh).
And also include the TOC file (to see if it's using RW or RW_RAW format).

(If it's possible to dump discs in both RW and RW_RAW format would be even better.)

[alexfree]

PS. Easier way to figure out what RW and RW_RAW are:
Can you dump a CDROM or Audio disc with CDRDAO in TOC/BIN format, with subchannel data?
And post a hexdump of the first sector's subchannel data (it should occur at BIN file offset 930h..98Fh).
And also include the TOC file (to see if it's using RW or RW_RAW format).

(If it's possible to dump discs in both RW and RW_RAW format would be even better.)

I dumped a real WipEout USA PSX game disc:

Code: Select all

[alex@fedora wipeout]$ ../cdrdao read-cd --read-raw --read-subchan rw_raw --driver generic-mmc-raw wipeout.toc
/dev/sr0: HL-DT-ST DVDRAM GP63EX70	Rev: RF01
Using driver: Generic SCSI-3/MMC (raw writing) - Version 2.0 (options 0x0000)

Reading toc and track data...

Track   Mode    Flags  Start                Length
------------------------------------------------------------
 1      DATA    4      00:00:00(     0)     05:30:71( 24821)
 2      AUDIO   0      05:30:71( 24821)     05:15:31( 23656)
 3      AUDIO   0      10:46:27( 48477)     05:22:09( 24159)
 4      AUDIO   0      16:08:36( 72636)     05:05:65( 22940)
 5      AUDIO   0      21:14:26( 95576)     05:15:51( 23676)
 6      AUDIO   0      26:30:02(119252)     05:16:72( 23772)
 7      AUDIO   0      31:46:74(143024)     05:18:72( 23922)
 8      AUDIO   0      37:05:71(166946)     05:26:35( 24485)
 9      AUDIO   0      42:32:31(191431)     05:05:44( 22919)
Leadout AUDIO   0      47:38:00(214350)

PQ sub-channel reading (data track) is supported, data format is BCD.
Raw P-W sub-channel reading (data track) is supported.
Cooked R-W sub-channel reading (data track) is supported.
PQ sub-channel reading (audio track) is supported, data format is BCD.
Raw P-W sub-channel reading (audio track) is supported.
Cooked R-W sub-channel reading (audio track) is supported.
Copying data track 1 (MODE2_RAW): start 00:00:00, length 05:28:71 to "data.bin"...
Copying audio tracks 2-9: start 05:30:71, length 42:07:04 to "data.bin"...
Track 2...
Track 3...
Track 4...
Track 5...
Track 6...
Track 7...
Track 8...
Track 9...
Reading of toc and track data finished successfully.
[alex@fedora wipeout]$ 

Attached is contents of 0x930 through 0x125f (0x930 bytes) of the .bin file, as well as the .TOC file.

I forgot to mention, the image does work. I'd suspect that a LibCrypt game ripped and then burned like this should work as well, but I still don't have a real LibCrypt game. I could try CloneCD burning a LibCrypt backup I guess, and then ripping that.

[alexfree]

Awesome, my bug fix is now in the official cdrdao dev branch: https://github.com/cdrdao/cdrdao/pull/1 ... 8353495533

[inc^lightforce]

Sounds all good and maybe it is a nice Research at all, but honestly, 22 years too late we managed the Problem with CODE Back in the days.

But, Go for it. Big up

[alexfree]

I've updated https://alex-free.github.io/cdrdao to instead have a portable Linux x86_64 download of the latest dev branch of CDRDAO (which includes the bug fix). There is also a bunch of info on burning and ripping CDs with CDRDAO.

[alexfree]

I've released EDCRE (made possible with CDRDAO source code) which allows hacking EDC Protected games and burning them on real hardware with working changes: https://alex-free.github.io/edcre . On that page is also a ton of info on this EDC protection stuff found in almost all of the Dance Dance Revolution PSX games.