GD-ROMs - Do they have copy protection other than inharently being a diffrent format?

Hey Everyone,

Does anyone know if GD-ROM's have copy protection other than inherently being in a different disc format? If so, is there any information on what it employs?

 

AFAIK they do not. In fact, the GD format itself is readable by a standard CD drive from what I remember, it's just a matter of reading the second TOC after the security band. I have a side question, do Katana GD-Rs have a security band or do they just burn the GD data straight?

 

It can be read by some/most drives with a "trap disc" but you still have to play with the data in order to get something useful from it.

GD-Rs lacked the security band (which is also present on Saturn discs) which is why they won't boot in a retail Dreamcast. The System Disc 2 would be popped in first (as it does in fact have the security band), booted and then you'd swap in a GD-R. I don't think anyone has ever bothered to try writing a Mil-CD based image to a GD-R to see if a Dreamcast can be booted with a GD-R in some fashion as the requisite hardware is rather expensive and takes a long ass time to do a test burn and then a real burn.

As for copy protection schemes as a whole? Absolutely none. I would imagine the fact that there wasn't a way to make a 1:1 copy made plenty of sense in that regard. Absolutely no GD-Rs for public consumption were ever made nor was the technology made into anything. GigaRec technology is however functional with the Dreamcast if you burn a CD-R with it though I don't know what it has in common that allows for this beyond the fact the discs were intended to be readable by anything that could read standard CD-Rs. The Dreamcast only booted CD-Rs because they were in a Mil-CD format which had no copy protection at all by design. I have no idea why this hole was left in the BIOS but I would assume the engineers thought no-one would be able to find it.

That said SOME games had a form of copy protection. Sonic Adventure 2 had invisible holes in a few levels that your character would fall into and make it impossible to finish the game. You can find a rip or two out there that mention this as being fixed in their particular release. Other games would have odd behavior upon trying to use audio that had been resampled so it could fit on a 700mb CD-R. I believe this was the main issue with Skies of Arcadia which is well known to have had its textures recompressed and a decompresser do its job on the fly care of Echelon.

D2 also pushed the GD-ROM format to its limits and used practically every available byte available. I've never seen any documentation to confirm this but I'm 99% sure there was some oddball type of copy protection on D2 that prevented it from just being burnt to a CD-R. It was never made into a release by any group aside from the first Disc for a VERY long time. I know a rip exists that has all four discs with just resampling done to the audio and video. I would imagine the game did basic checksum tests on all of the audio and would have undesriable behavior upon failing them. Can't say what kind as I'm just hypothesizing atm.

 

Edit:

Ops APE explained it already ... lol sorry...

As I mentioned on my main text, The System disc2 has an special barcode which is different than what you find on a normal disc. Because of that I don't think a MIL-CD rip of it would be of use for anyone besides an curiosity.

The copy protection bits are of course very interesting stuff and I suppose it has to do with Dreamcast being pirated so fast that the game companies could not recover their investment from developing the titles.

Sad history.

And sorry about all these edits on this post.

Original text:

 

I confirm first hand that backed up mil-cd copy of SystemDisc2 doesn't work at all.

FG

 

Interesting. Any idea why?

 

Maybe the ring l_oliveira mentionned is needed for the soft-reset to be handled correctly ...

However, the disc boots and everything! When you try to reboot into a GD-R (the aforementioned soft-reset) it only reboots normaly, without being able to boot a gd-r.

I've made my cdi with a raw/2352 untouched GDI rip and tried everything to make it works. And i'm no n00b at booting DC games if you're wondering ... ;-)

Unless it requires extremely complex hacks, I'd say it's impossible to make this one works as expected.

I guess though, and I've had this idea before for bleem!cast, that to "dump" the ram (or "state") of the DC when the disc is loaded then create a custom disc that would restore the ram (state) of the DC would works ...
It's completely out of my league though ...

Cheers,

FG

Edit: Also AFAIK only the Lite-On LTD-165H DVD-Reader can read a GD-ROM completely, not all disc though, as an exemple trickstyle is IMPOSSIBLE to dump 100% NO IDEA WHY!
I made a small tutorial on that topic in french there: http://dreamagain.free.fr/index.php...ft-ripper-un-gd-rom-avec-le-lecteur-de-son-pc
Not-so-bad google translation: http://translate.google.com/transla...ft-ripper-un-gd-rom-avec-le-lecteur-de-son-pc

 

You've stumbled on a secret of sorts. For as long as I can remember Lite-On drives can read just about anything you can imagine which made them particularly useful for backing up various discs regardless of what type of copy protection they used. I wouldn't be surprised if most Lite-On drives could dump GD's. I switched to them on the reccomendation of a friend in my hacking/cracking days (which are long behind me) after my brand new MSI drive died within a couple of months and never looked back

 

Well I never heard of other drives working 100% at all, even lite-on ones. In fact you have to rip it in two parts: 45000 -> X and then X+1 -> 549150, where X=~369999.
I've seen lots of (lite-on) drives that don't work, beside the holy LTD-165H.

FG

 

Like you said, GD-ROMs have a security band, and this serves as copy-protection and prevents you from being able to make a 1:1 copy of a GD-ROM. This of course does not prevent transfer to MIL-CD. This protection was (afaik) built into the BIOS.

I can't recall quite where I participated in a more in depth discussion of this (although I do recall more than one with drkIIrazi) but this protection relied on some undocumented SPI commands of the GD controller (0x70, 0x71, and 0x72 iirc). The working theory was something along the lines that these commands worked together to read the security band.

 

Don't you just love being so asleep that you come up with the answers to your own questions and not realizing it?