Ps & CloneCD

Please experts, give me some light in the following issues regarding Playstation LibCrypt and Clone CD.

As i know playstation it performs two checks on the CD inside the PSX. One of these checks looks for the country code, which tells the PSX what country the CD was created in. If the code matches the code that is located in the PSX BIOS (Basic Input/Output System), the boot procedure will continue. For example, a Japanese CD is not playable on a US Playstation because of the country code check. The second check looks for bad blocks at certain locations on the CD. Since only Sony’s CD recorders can produce these, the presence of bad blocks tell the PSX that the CD is authentic. If they are not there, the PSX halts the boot process.

The Question is:

Is the country code copied with CloneCD ? for example if you copie a US cd, the clone must have the same country code so the first check passed in a us PSX.

The second check is the bad blocks, due to 1:1 raw copy of clone cd, bad block must exists also on the duplicate.

If both of the abone checks passed, the psx must boot the cd without Modchip. But it doesnt. WHY?

I am confused, please help :confused:

Thanx,
Nimrod7

Straight from the CloneCD FAQ:

[i]I have a game console which uses CDs. Can I copy these CDs with CloneCD?

Sure you can copy them! But the question should be - will they work? And the answer is: No. CloneCD does not disable the boot protection found on console CDs. As we already said, CloneCD does not modify the data it reads or writes in any way.
However, if you have modified your game console already to accept backup copies, copies created by CloneCD will work. There is even a nice side effect: Almost any additional copy protection (apart from the boot protection) will be copied, too. Backup copies created with CloneCD will therefore work better than copies created by a different program. However, CloneCD was designed to make Safety Backups of PC-CDs, not for game console CDs.[/i]

That description from CloneCD is a bit vague and a little incorrect. I would say a bit of a dumb answer (don’t get me wrong, I respect the author), but I think the guy wants a bit more detailed and a more correct info on this - for the curious…

It’s not CloneCD’s fault, but how the country info is stored on the CDs.

About the incorrect info:

  1. No one said that the solution was to modify the data!! Even doing this will not allow booting without mod chip!! So I don’t see why this is mentioned anyhow.

  2. Also, the solution is not to disable the boot code (which can’t be done anyway). What we want is to try and copy it.

  3. CloneCD does modify data it reads (well, just before writing it in memory) - the option of making weak sectors strong.

Anyway, someone mentioned this before…

The country code info is stored where it is unreadable (well by our readers), probably in the ATIP and the writer cannot write to this area.

I hope this clear things up and CloneCD should revise the description.

  1. Yes - you do need a mod chip to play PS backups. No question there.
  2. I agree.
  3. CloneCD does not modify data, even with AWS on. What AWS does is allow the original data to be accurately burned. A “weak sector” is a specific (repetative) series of 1’s and 0’s that fool the CD-R into recording them wrong. Without AWS, the original data is not recorded correctly. With AWS, the exact original data is copied. A few burners can do this copying without the AWS turned on - that series of bits do not fool them. I believe that Lite-Ons and Plextors can do this copying without AWS in CloneCD.

I get your point. But modify in my dictionary means change.

AWS works by changing those repetitive 1s and 0s to a different pattern in memory (RAM) so that they get copied as original repetitive 1s and 0s on the CDR. Overall I think you get exact copy of original data on CDR - but still the data was changed somewhere in the middle process (in memory). So this to me constitutes a modify!!

I think the word modify isn’t the right word to use. It should be said that data isn’t modified on the copy or the image - however it is modifed in memory - which is fine by me as long as the job gets done - but they shouldn’t play with words.

Are we talking English?

That’s as good an understanding as I have of it - I guess that Oliver Kastl would be the one to ask for a better explanation. Sounds good to me.

Originally posted by Truman
AWS works by changing those repetitive 1s and 0s to a different pattern in memory (RAM) so that they get copied as original repetitive 1s and 0s on the CDR. Overall I think you get exact copy of original data on CDR - but still the data was changed somewhere in the middle process (in memory).
What’s the point of changing the data in RAM, if this is the case, if it ends up the same on the CD-R? Olli has already stated that what can’t be read can’t be copied :wink:

@dr_zeus

With AWS, the exact original data is copied

A copy, created with AWS is definately not a original copy.
Try to read the copy again with BlindRead/Cdrwin:
The weak sectors are gone (CloneCD seems to create them somehow again).

Isn’t there any burner, which is able to read/write the barcode (PSX copy protection)?

Originally posted by little-endian
[B]@dr_zeus

A copy, created with AWS is definately not a original copy.
Try to read the copy again with BlindRead/Cdrwin:
The weak sectors are gone (CloneCD seems to create them somehow again).

Isn’t there any burner, which is able to read/write the barcode (PSX copy protection)? [/B]

Is that a barcode on the data of the cd or some barcode in the center , non data part of the cd ?

Perhaps the new series of writers that can burn images in cd’s can also write barcodes ?

As far as I know, the barcode is before the Lead-In and that’s why (almost) no reader can read it.
I hope, that there are exceptions.

Originally posted by little-endian
[B]@dr_zeus

A copy, created with AWS is definately not a original copy.
Try to read the copy again with BlindRead/Cdrwin:
The weak sectors are gone (CloneCD seems to create them somehow again).

Isn’t there any burner, which is able to read/write the barcode (PSX copy protection)? [/B]

Yes, i have to agree with you… CloneCD does modify the weak sector, so non capable CD-Writers are able to write them, then if the data is modified, it’s not 1:1, and also if you read with ECC disabled, you will get that patched sector but not the orgianl weak sector, which I can say, not 1:1…
And what do you mean by gone?
The patched sectors are gone or? :eek:

@softwareguy

I mean, the weak sectors are gone (on the copy).
But if you read your AWS copy with CloneCD, your image will contain still these weak sectors. But only if you read with CloneCD, all other progs will return the patched sectors, except on originals. In this case, they will give you weak sectors, too.
So the fault must be CloneCD’s …

For more info on the weak sectors just read the threads in the CloneCD experienced users forum! AWS does modify the data, but when reading back the data, ecc kicks in and corrects the modified (less) weak sector back in to a ‘real’ weak sector…

Originally posted by little-endian
[B]@softwareguy

I mean, the weak sectors are gone (on the copy).
But if you read your AWS copy with CloneCD, your image will contain still these weak sectors. But only if you read with CloneCD, all other progs will return the patched sectors, except on originals. In this case, they will give you weak sectors, too.
So the fault must be CloneCD’s … [/B]

Sorry I think, I have mixed up some things here, and so I have to deny my claims:

I’ve checked the AWS results again, and it seems, that CloneCD is not the only program, which gives you weak sectors.
In fact, every prog will give you the same result, except BlindRead’s alternative read method (reading data as audio with corrected offset).
If you read your AWS copy with this mode, you’ll get the patched sectors in your image, like they’re on the CD.
So no ECC comes in, like Upp3rd0G told, and that would mean, this mode is somehow “rawer” than every other “raw” mode, inluding CloneCD’s one (even with error-correction set to “none”).
Unfortunately Olli doesn’t make a move to implement this audio reading method into his CloneCD.

Sorry again for the wrong info before …

Since this is about PS backups I have a sidenote.

I knew that backups would not work without the chip mod (but I had to try it anyway). However, to my surprise PS backups do work on Connectix’s Virtual Game Station 1.4 for Windows.

To the best of my knowledge, Virtual Game Station was the only commercial AND legal PSX emulator. Unfortunately, Connectix discontinued it.

bleem?

Of course, PSX emulators can’t perform a barcode check, because no known CD-ROM reader is able to read it, exactly this is the problem. So no CD would run, no matter if original or copy.
This would make emulators quite senseless …

Thanks! I didn’t understand the mechanism. That makes sense.

IM Confused cause I see here


"Nov 2001 - Thanks goes to InSOMniA for submitting this extra info…

Back-ups made with the AWS option are still 1:1 copys… and a future version of SafeDisc 2 will not be able to see a difference between a copy made with the AWS option or a copy made with a ‘EFM’ compatible writer… "

So do I want to use AWS or not?? (but id still like to know if the AWS option is necessary or doesnt really matter, cause most people probably had it enabled anyway)

Hi flakeup,

pretty brave to reply to such an old thread, but you
have luck - I was notified. :slight_smile:

My advice is the following:

Only use AWS if the burner doesn’t produce working backups, otherwise. The more sheeps your burner has, the more patterns can be recorded which are readable after - especially for other readers. But don’t worry, even if you have got one of those so-called “2-sheep-Burners”, you won’t be able to reproduce all weak patterns which are possible.

A copy made with AWS enabled is definately not a 1:1 copy (it is already a question of definition if 1:1 copies from protected CDs are possible, at all), since patched sectors are written, then.
The SD2 guard module can’t distinguish between original and copy because it will get the unpatched sectors in both cases.
As far as I know the modified bytes are converted on the fly because EDC/ECC kicks in while reading. The only way to determine what is really on the disc, seems to be to read the copy with either Truman’s Tool (EDC/ECC off) or BlindReads audio method.

I hope, this clears some things up for you.

little-endian