I wanted to see if it was possible to dump the gamecubes disk's data content using an old xbox360 drive. I had this idea after looking at the friidump source code, this program uses Hitachi vendor defined debug commands to read / dump the raw data sectors of the gamecube disks. The old xbox360 drive I had was a Hitachi GDR3120L/0047 this drive was not supported by friidump but it looked close enough.

I connected the drive up to the pc using team xecuter CK3 lite connectivity kit, this bit of kit puts the drive into modeB so that windows see's the drive as a normal dvd drive and not a xbox360 drive. I first tried to dump the disk using friidump 0.3 and it did read the first data sector correctly stating that the game in the drive was a gamecube game. It also stated that it was a europe / PAL disk and the game title was star wars rogue squadron, this was a good start however it crashed when it tried to write data into a ISO file.

So I started digging around in the source code and found that the file name lengths looked to long for windows standard fopen function, I had a look around the web to find a way to open long file names (44 characters). The answers I found all looked very M$ orientated (using _wchar etc) so I decided to use only the first 8 characters of the game title and then add .iso extension. This got me a little closer to a working dump program that used the xbox360 drive, however the program would not correctly read the data sectors. It would start to read the data sectors but would repeatedly  fail the edc checksum test on a sector and stop.

I decided to look into the unscrambling code and found that the tap values for the dvd scramblers LFSR didn't look correct, page 25 of ECMA-267 (the DVD spec) states the tap values should be at r10 and r14. I also noticed that friidump was brute forcing the dvd seed values for the gamecubes disk drive as it the time of writing the program the seed calculation was not known. I corrected the tap values and generated the unscrambling stream with a LFSR seed value of 1. I then used the tmbinc's gamecube seed index calculation

#define DVD_PRE_SET_OFFSET 0x800
#define GAMECUBE_OFFSET 0x3C00

/* use gamecube seed index calculation */
seed_index = ((((sector_no & 0x000000F0) >> 4) ^ GameIDChecksum ) * DVD_PRE_SET_OFFSET ) + GAMECUBE_OFFSET;

to calculate the correct index into the unscrambling steam to use for each gamecube data sector. I cant work out the value to use for GameIDChecksum (Had to reverse engineer some of the gc disk drives source code but worked it out in the end read the update below) so at the start of the program it now loops from 0 to 15 (the only values GameIDChecksum can be) and tried to unscramble sector 16. If the edc passes for one of the values (0 to 15) it breaks out of the loop and uses this value as the GameIDChecksum. As the GameIDChecksum is per game constant, this appears to work correctly.

Please see the link below for more information on this constant / calculation


However the program still didn't work correct it still failed some of the edc sector checksum, I really cant see why this didnt work, sigh it took me a while but I finally got it working. For some reason the xbox drive didn't like reading 5 * 16 sectors at a time like the other Hitachi drives it only likes reading of 4 * 16 sectors at a time. I corrected the disc_read_sector to read 4 * 16 sectors at a time and instead of 5 * 16 and it dumps the gamecube disk correctly now :-)

Heres the source code (updated code is below don't use this one) and binary its basically a reduced version of friidump built using dev-cpp, it reads 4* 16 sectors at a time for all the supported Hitachi drives plus the xbox360 drive. To keep things simple it only dumps the data to a *.iso file. To use simple type on the command line

gcdiskdumper disk_drive:

replace "disk_drive" with the name of your Hitachi drive for example gcdiskdumper f:

and hopefully if all goes well a iso file should be generated that contains the dumped game, it dumps a game in approx 1.5 hours. All credits go to the friidump author without his code this little program would not be possible.


The GameIDChecksum hack I put in really started to bug me so I went through some of the gc disk drives source and found out it uses the following algo to create the GameIDChecksum. You first add all the gameid bytes (six in total) together to get gameid_sum. Then it does the following

GameIDChecksum = gameid_sum + (gameid_sum >> 4)) & 0x0f;

I updated the source code to use the algo above so the source don't brute force or try to guess anything now much better :-)


As I was updating the code I though it would be nice if GCDiskDumper also dumped the BCA (burst cut area) / DMI(disk manufacturing information) /PFI (physical format information) areas of the disk at the same time as the main data / code area. I added DVD drive commands to request these areas however I found that on stock Hitachi GDR3120L/0047 firmware only the DMI area returns valid information.

Well the PFI DVD command does return data however it reports byte 16 (BCA description) to be zero (BCA does not exist), odd as I can see from the disk markings that it does exist. As this byte is set to zero in the PFI when I send the get BCA DVD command the drive sends back zeros, looks like big N don't want anyone looking at the BCA of there dvd's.

I hacked the Hitachi GDR3120L/0047 firmware to ignore this byte by editing the following part of the firmware

ROM:9002E4B3 loc_9002E4B3:
ROM:9002E4B3     btst 4, (0xABE)         // do we have a BCA ?
ROM:9002E4B8     bne 0x9002E4BE    // yes process request
ROM:9002E4BA    mov 0xA, D0
ROM:9002E4BC    bra 0x9002E4E6     // else error and return for bca


ROM:9002E4B3 loc_9002E4B3:
ROM:9002E4B3     bra  0x9002E4BE      // always process BCA request :-)
ROM:9002E4B8     bne 0x9002E4BE      // yes process request
ROM:9002E4BA    mov 0xA, D0
ROM:9002E4BC    bra 0x9002E4E6       // else error and return for bca

So now the drive just gives me the BCA I requested instead of giving me zero's although this firmware hack gets me the BCA data I wouldn't recommend it as a permanent update as it makes the drive unstable %10 of the time (drives freezes / locks up).

Its interesting to note that the first 16 bytes of my copy of phantasy star online BCA

A9 20 98 65 92 F5 12 2C B6 BE 05 37 1C 0C 08 5D

match those posted by tmbinc interesting looks like a key to decrypt / descramble the rest of the data, wonder what algo is used to decrypt that data.  

here is the updated code that dumps the extra areas.