The last remaining psx boot secrets

vbimport

#1

http://groups.yahoo.com/group/psxdev/

From: Mario
Date: Mon Sep 21, 1998

The Yamaha CDR-100 has not (and never has) had the ability to write the PSX
protection. Infact, most CD-R drives would require alot more than simply
modifying the firmware, as your not talking about simple EDC based (C2)
errors as most people seem to believe.

From: Mario Torbarac
Date: Sun Sep 27, 1998

The 'SCEx' string comes off a certain location on the CD, but it is parsed
by the Motorola microcontroller and that parsed string is what is returned
to the kernel/OSD. The Morotola microcontroller makes the decision as to
the locality and authenticity of the CD currently inserted - not the
firmware. The SCEx code is located within the Motorola microcontroller. The
firmware (or kernel and OSD) have SFA to do with it. As for the Blue (or
Green) development units, their microcontrollers are programmed to ignore
whatever value is there and will return a string of 4 spaces to the kernel
instead.

> As for blues and blacks: these machines still check against their code in
> the firmware, but are different in a way that still allows certain other
> codes. For example, on an american blue (DTLH-1101), legit american CDs
> will show SCEA tm on the screen, because the code matches. If a
> nonmatching protection code is received but is still allowed, such as
> imports on black/blue and copies on blue, " " is the protection code,
so
> you don't see anything. A legit Yaroze boot CD has a code of SCE
something

It is "SCEW". Which according to Icepic is for 'World'.

From: Barubary
Date: Wed Jan 20, 1999

Translation of the CdControl stuff (all hex):
1. Com 19 (???), param 20: Retrieve ROM timestamp (BFC00100 is where this
data comes from???)
2. Com 01 (CdlNop): Get CD status
3. Com 07 (CdlStandby): Keep CD-ROM drive ready
4. Com 02 (CdlSetloc): Set seek target to MSF 01:01:01 (sector 4426)
5. Com 0E (CdlSetmode): Turn on CD-DA read mode
6. Wait 3 root counts? (unsure of translation)
7. Com 16 (CdlSeekP): Seek to Setloc's parameters (4426)
8. Com 0B (CdlMute): Turn off sound so CdlPlay doesn't play data sectors as
audio. (NOTE: This is NOT needed - the PSX auto-mutes when CD-DA playing
data sectors.)
9. Com 03 (CdlPlay): Start playing CD-DA.
10. Com 19 (???), param 04: ???
11. Wait 150 root counts? (unsure of translation - I know 150 counts is
there - the english word "count" is written in that sentence. root is the
part I'm unsure about.)
12. Com 19 (???), param 05: ???. Store the return value.
13. If result[1] != 0, then you have a mod chip.
14. Com 09 (CdlPause): Stop command 19.

From: M. Williams
Date: Wed Dec 8, 1999

the psx cd drive cant sub-codes or multisession disks,
the psx's cdrom drive only works with CD-XA, CD Audio and CD Mode2 ISO.
and i like the idea of the copy code is already on the special Sony cdr writables.

From: A. Kieschnick
Date: Thu Dec 9, 1999

The protection is part of the motorola cd controller itself. The cd controller is a
microcontroller of some sort, with its own rom, which can't be replaced
easily (the controller + its rom + who knows how much other stuff is all
integrated together into some custom chip). This comes from my
recollections of conversations held long ago, but I believe I remembered
the general idea correctly. Really now, if the protection was in the bios,
it would have been cracked long ago...
later, Andrew

From: blaknite
Date: Wed Dec 22, 1999

The "SCE" has got to be in the area of the disk around the T.O.C.
The laser head would not be reading from inside the data track untill
after the machine has already booted. It would however be normal for
the psx to read the subcode in the Table of Contents at boot up. The
T.O.C. is actually written in the Q channel of the cd subcode.

Giving this Idea some more thought, I read somewhere that the subcode
data in the Q channel must exist in 9 out of 10 consecutive sectors.
It might be possible for the "SCE" to be in the 10'th. Or it could be
in one of the other channels being read simultaneously with the T.O.C.

From: Barubary
Date: Sun Jan 2, 2000

If you do not have a mod chip installed, pin 6 should only be active when
the PSX is checking copy protection (reading the table of contents, as
that's where the protection data is).

Pin 5 of the mod chip disables the internal generation of the data on pin 6.
If you were to connect pin 5 to VCC (or to a mod chip) without connecting
pin 6 to anything, the PSX would think all CDs are copies, as no SCEx data
is being sent. If pin 6 is connected to a mod chip and pin 5 is not
connected to the chip or VCC, legits will fail and only copies will work.
This is because the mod chip generates the SCEx data, but if the CD is legit
and the internal SCEx is not disabled, you have a bus fight over that pin
and get garbled data. Copies work because nothing goes over pin 6 during
this time.

Pin 6 is a 300 bps inverted serial stream (its clock is on the board as
well, but the internal clock of the 12C508 is accurate enough to mimic this
speed in PIC software). Across it is transmitted the bytes "SCEA". Mod
chips send SCEISCEASCEE continuously so as to pass each region's protection
check. -- Barubary

From:avh
Date: Sat Jan 22, 2000

hmmm... ever had a look at the "secret" CdCountryChk function???
CdCountryChk returns = { 22 00 22 00 'S' 'C' 'E' 'E' 22 };
+0 +1 +2 +3 +4 +5 +6 +7 +8
that's also where SONY hides the "magic" key for their so-called
LibCrypt protection ...
in fact the country protection looks like a hardware-based
SecuRom protection, and LibCrypt is just an improved version...
check SecuRom infos at: http://www.securom.com/nets/index_general_nets.htm
cheers, -AVH-

From: Alex
Date: Sat Jan 22, 2000

Hi all, Here are some informations that may help !!!
Actual data that gets injected to psx:

09h,0a9h,3dh,2bh,0a5h,0F4h ; U.S.
09h,0a9h,3dh,2bh,0a5h,074h ; European
09h,0a9h,3dh,2bh,0a5h,0B4h ; Japanese

This code is then pass to another chip
which will decode in the ways shows
below example for USA disc:

0x9, 0xA9, 0x3D, 0x2B, 0xA5, 0xF4

In binary:

1001 10101001 00111101 00101011 10100101 11110100

Expand into bit groups with 1 start bit (high) and 2 stop bits (low):

1 00110101 00 1 00111101 00 1 01011101 00 1 01111101 00

Remove start & stop bits:

00110101 00111101 01011101 01111101

Reverse the bits of each byte/group:

10101100 10111100 10111010 10111110

One's complement:

01010011 01000011 01000101 01000001

Back to hex: 0x53, 0x43, 0x45, 0x41

Now, to ASCII: S C E A

I tried to inject other combination of codes like "SUCEOOOOOOI", still get
passed. ILLEGAL chars simply ignored !!

From: Tursi
Date: Wed Feb 2, 2000

Nobody who knows seems to be talking, but I do know one thing that suggests
the Sony CD Writer can not write bootable disks - authorized PSX developers
who send out CDR betas to magazines and the like for review - these CDRs
will not boot on a normal PSX. If they could, I'm sure they'd use this
"magic" drive for the reviewers.

It seems likely that the Sony CD writer would have fallen into SOMEONE's
hands and been written up over the years if it really could make protected
CDs. We keep running in nice little circles here.

From: blaknite
Date: Thu Mar 2, 2000

I'm almost positive that the license-string-code really is on the disk. If it was
a chip that output the code, sony would have changed the data the chip
generates with later releases of the PSX. The one thing sony couldn't
change was the code on the actual CD. (It's not definate proof, but it's a
strong argument.)

How do you know that there isn't data on the line all the time? The
tristate inverter chip that the mod chip injects the signal in front of
could be to split the signal. That way, the subcode signal could go to the
position decoder circuit on one line, and to the cpu for the protection
check on another. That (I think) is why the mod chip can cut off the
signal without affecting the functionality of the PSX.

From: blaknite
Date: Fri Jun 9, 2000

There is data where
the mod chips signal is injected all the time that the cd is reading, not
just when the license string is transmitted.
From viewing the logs, I am pretty sure the license string is not at
the EFM level. I think this is good news because you would have to build
your own burner to write incorrect EFM.

From: "A. Souza
Date: Mon Jan 15, 2001

How a mod chip works? Inserting the string "SCEASCEESCXX" in a channel, eh? So
tell me: you can count how much "sectors" the head advances? So why not count
the sectors and display the number when the SCXX string appears on this
channel??? Can you understand what I want to say?

From: "J.Brown
Jan 16, 2001

It's a strata thing.
The data recorded on the 'black cds' has a certain patch overwritten with
offset'ed data. This is a deliberate 'manifacturing defect' - the defect
in the CD alters certain laser depths to return systematically mangled
data. Basically it'd require a hidiously modified CD - manifactured specially..

The problem is the SCEA string isn't in plain-data on the CD. It's
overlayed in a lower strata over GENUINE data that only the specialised CD
controller can see.

From: blaknite
Thu Jan 18, 2001

  1. Real PSX disk
    The license string is contained read 3 or four times as the disk starts up.
    It is among alot of random binary data.

  2. PSX backup
    The random binary data exists, but not the license string(obviously). It
    is not even partially there which suggests that the license data is not
    simply mangled by an error correction scheme. Rather it is never attempted
    to be written.

  3. Audio CD
    Again there is random binary data on the line on every disk I tried.

  4. Audio CD-R
    Some disks I tried the binary data was there, some It was not.(all zeros)

Possibility: The data is based on a third factor such as the depth of the pits in the
disk, misalignment of the radial track, ect. I would almost rule out this
possibility because not only would the disk have to be manufactured extremly
precisely, but also every playstation would also have to be extremely accurate
to determine these factors. Everyone knows the quality of the laser unit in
a SCPH-100x.

From: Barubary
Fri Jan 19, 2001

I wrote a custom, shitty but usable CD
writing program that read lead-in raw,
complete with sub R-W data, and wrote
it back.

This is the sub-Q data I found (sub-Q in leadin is the table of contents):

41 00 A0 97 22 33 00 01 20 00 8C 2D
41 00 A1 97 22 36 00 01 00 00 EE 4F
41 00 A2 97 22 39 00 29 14 29 16 58
41 00 01 97 22 42 00 00 02 00 AD 74

97 22 33..44 is the timestamp in leadin (this is an MSF address; leadin
increases from 97.??.?? to 99:59:74, then goes to 00:00:00)

The last 2 bytes are the EDC for sub-Q data.

*** This could be our chance! Just write a modified RAW 2448 Lead In. And because as good as the whole Lead-In consist of "00's", its no problem to edit some "FF"s into it. Only find the right place. Using an Boot-Process Emulator would be a must to check out the adequate combination!

CU, Sam