|
In order to understand most of the rest of this document,
you need to understand a few basic things of the copy protection system of the PSX. This
is all closely related to why FF8's protection system exists at all.
Somewhere, on black PSX CDs, is an ASCII (IE, letters) string. This is how the copy
protection works. Not even I know where it is, but I do know what form it's in. These 4
(known) strings are: SCEI (Japan), SCEA (America), SCEE (Europe/other PAL places), and
SCEW (Yaroze). Look familiar? They should. On the black PSX screen, there is this (for
American games on American gray PSXs):
Licensed by
Sony Computer Entertainment America
SCEA tm
Since the location of this data is unknown, when you copy CDs, you don't copy the SCEx
data on the CD. This is why you need a mod chip.
Each PSX has a particular SCEx "code" it waits for. American PSXs look for SCEA,
for example. When you stick in a CD, the PSX waits for its particular code, and if it
doesn't find it it considers it an invalid CD. All invalid codes are ignored.
QWETKSDFUSCEAIRGTKVL is a valid code for American PSXs because the other letters are
ignored and it sees SCEA. If a 3rd party developer figured out the copy protection, they
could have a licensed code of NOTLICENSEDBYSCEASCEIORSCEE and get through the copy
protection.
From CD-ROM PSX wants Comments Correct? Result
-----------------------------------------------------------------------------
SCEA..SCEA..SCEA.. SCEA American CD Pass..Pass..Pass.. -> Valid CD
SCEA..SCEA..SCEA.. SCEE American CD Fail..Fail..Fail.. -> Invalid CD
SCEI..SCEA..SCEE.. SCEA Mod chipped Fail..Pass..Fail.. -> Valid CD
.................. any Copy w/o mod .................. -> Invalid CD
THE COPY PROTECTION IS THE SAME AS THE IMPORT PROTECTION. Each PSX (excepting blue and
black PSXs) has only 1 copy protection code that it recognizes. This is how import
protection is done. See the above table,rows 1`and 2. The first is an American PSX, the
second is a European PSX.
The 3rd one on that table above is the one of interest. If you have all 3 codes on the CD
(which Sony never does but it in theory possible) it will work with all PSXs. This is the
technology of the mod chip. The inventor of the mod chip (who is, contrary to conventional
wisdom, NOT Old Crow) found a way to fake the SCEx data from the CD-ROM. A method of
putting anything you want instead of the SCEx was discovered. At first, mod chips were
"burned" according to what PSX the mod chip was being installed to. Mod chips
destined for American PSXs sent SCEASCEASCEASCEASCEA... to trick them.
However, people began to notice how much of a pain it was to make 3 different types of mod
chips. Someone (probably Old Crow) figured out that if you send SCEISCEASCEE instead of
only 1 code, you will have a mod chip that works on any PSX. This, and the discovery of
the "gate"/"pin 5" wire,
led to the name "Universal Mod".
So that mod chips don't need more than 4 wires (the absolute minimum for non-American
PSXs), a decision was made that it doesn't matter WHEN the PSX checks copy protection. The
mod chip just sends data continuously from when you turn the PSX on until you turn it off.
This shortcut turns out to be why the mod chip is detectable at all. Unmodded PSXs only
send the SCEA a few times before turning off.
I hope this explanation was enough to explain why mod chips work the way they do, as the
next section says how the FF8/Poporogue copy protection takes advantage of the design of
mod chips to work.
| 2. How the New Protection Works |
If you look above, you'll see that the normal (IE,
unmodded) operation of the PSX only has the SCEx code data during bootup, while modded
operation sends the data continuously, even when it's not wanted. Because of this, it is
possible to detect mod chips by seeing if data is being transmitted during times when
normal operation wouldn't. In fact, this is exactly what is done by FF8.
With the release of Poporogue (the first "mod-detecting" game) in Japan, many
people wondered what was going on that was detectable. With the help of some HK crackers,
the programming team that made Caetla figured out what Poporogue was doing to check
protection. It turned out that another undocumented CD-ROM command (0x19), was able to
count the number of SCEx codes that had been received.
FF8's detection scheme is actually not too difficult to understand. First, it places the
CD-ROM in a "distracted" state. It plays a data track as audio (and blanks the
sound of course) apparently so that no SCEx data gets sent. It then sets the
"counter" to zero. If it receives SCEx codes, that means a mod chip is present.
If none are received, it means one isn't.
. = nothing
"Mode" SCEx codes Counter Result
-----------------------------------------------------------------------------
Normal .................. 0 -> No mod chip
Chipped SCEI..SCEA..SCEE.. 3 -> Mod chip
FF8 reads the counter data, and uses that to determine if a chip is
present.
A. Don't use a mod chip, or use swap trick/mod switch
If you don't use a mod chip, no SCEx data is sent during FF8's check, so obviously it
isn't detected. However, not using a mod chip is not very useful since you'll need a legit
FF8 and a Japanese PSX.
However, the "swap trick" and switchable mod chip work great. These methods work
because there is no SCEx data sent - there is either no mod chip or the mod chip is
disabled when the FF8 check is occurring. See section I.2 for more information.
B. Use an "anti-piracy" mod chip.
An "anti-piracy" chip works like this: the chip waits for SCE before sending the
A (or whatever letter is needed for that PSX). If even SCE is received, it has to be a
legit CD. This is how it plays imports and not copies.
Conditions SCEx data PSX sees Result
-----------------------------------------------------------------------------
Legit From PSX SCE...SCE...SCE... SCEA..SCEA..SCEA.. -> Valid CD
From Chip ...A.....A.....A..
Copy From PSX .................. .................. -> Invalid CD
From Chip ..................
Since no data is sent during the check, the anti-piracy chip doesn't add add any and is
undetected by FF8's method. However, this could change easily, since there is a simple way
to check for anti-piracy chips, one that could prevent imports from running AT ALL,
regardless of what type of mod chip you have. Not even stealth chips would fix it - it is
inherent to the PSX's design. For this reason, I won't be giving details out because if I
did then developers would use it.
C. Here's something a bit more obvious: crack the game.
This is by far the simplest solution if you can do it. As stated in I.2, there are several
direct crack methods available.
The crack itself works by basically skipping over the code. The code, in a pseudocode
QBASIC (chosen as the most people know it) form, looks like this:
' Original FF8 code
FUNCTION CopyProtect%
' Execute the CD-ROM commands used to get SCEx counter data.
NumberOfCounts% = StartCopyProtection
' If any were received, then fail protection
IF NOT NumberOfCounts% = 0 THEN
CopyProtect% = 1
EXIT FUNCTION
END IF
CopyProtect% = 0
END FUNCTION
What my crack does is jump over all of the protection stuff, instead starting at the part
at the end (CopyProtect% = 0). In QBASIC pseudocode form again:
' Cracked FF8 code
FUNCTION CopyProtect%
' Execute the CD-ROM commands used to get SCEx counter data.
' DELETED: NumberOfCounts% = StartCopyProtection
GOTO Skip ' ADDED
' If any were received, then fail protection
IF NOT NumberOfCounts% = 0 THEN
CopyProtect% = 1
EXIT FUNCTION
END IF
Skip: ' ADDED
CopyProtect% = 0
END FUNCTION
Basically, it just skips over the code. In reality, however, it is written in R3000 (the
PSX's CPU) assembly language, not BASIC. This QBASIC description works though because it
depicts accurately the crack itself. The 10000046 in the Game Shark codes, for example, is
a "beq zero,zero,???" R3000 command that means basically "GOTO".
(NOTE for programmers: StartCopyProtection is actually in-line (not shown here for
simplicity))
The jump itself is 1 instruction, or 2 Game Shark codes. In order to keep the game stable,
since FF8 shares RAM among different parts of the game (overlays), you need "D"
codes. D codes only activate the code under it if its memory location is a certain value.
This is so that you don't mess around with the wrong data.
Game Shark codes a whole lot different from a true crack. In order to make a real crack,
you must first make an EXE file (the SLPM file is an EXE). It's not as simple as yanking
out ye olde Hex Workshop and making a few changes that match those in the Game Shark
codes. First of all, the copy protection code is not in the EXE, but rather, compressed
somewhere on the monster file known as FF8DISC1.IMG. Second, RAM is reused.
My solution was as follows: Attach a "waiting" piece of code to the part of the
EXE that decompresses the protection code. As soon as the decompression code decompressses
copy protection code, my program kicks in and hacks it. However, this solution adds a new
problem: how to add in this code. There is simply no space in the EXE to add code, as the
00'd areas in the EXE get overwritten and the code needs to stay. I ended up choosing the
reserved RAM area at 8000F800 as the place for my code, which caused yet another problem:
how to get code into 8000F800. The PSX EXE format does not allow for using 8000F800 simply
by loading an EXE. In order to fix this, my final solution was made:
- Take over the start of FF8. This allows me to have my code
execute before FF8 even starts.
- In the code that starts before FF8, copy the
"attachment" to the decompression code I described before into 8000F800.
- Patch the decompression code to call 8000F800 every byte
that is decompressed (slow, but only adds 1 second to load time).
- Start FF8.
- When the copy protection code is decompressed, first make
sure that it is the right code that is being modified. (This occurs in 8000F800).
- If so, write 0x10000046 to 0x8009B2E0 (as shown in the GS
code).
- Resume normal FF8 operation.
I hope this clears up the many misconceptions about FF8.
Mr. T
Author |
