PlayStation Development Network

Something interesting I found when going to test MottZilla's new Stealth ROM build which among other things will add anti-piracy fixes is that I can't test it on my SCPH-1000 or SCPH-3000 consoles, because...

The anti-piracy checks don't work! And it actually is an amazing reason why, I saw it before I even tested his new build and couldn't belive my eyes when it in fact did not trigger.

The CDROM Controller has it's own BIOS version. On SCPH-1000 you are going to have a VC0 A September 19th 1994 or VC0 B November 11th 1994 version. All SCPH-3000 consoles will have the VC0 B Novemeber 11th 1994 version.

As stated by Martin Korth in the PS1 bible https://problemkaputt.de/psx-spx.htm the ReadTOC command (like many other commands) do not exist in either VC0 A or VC0 B. It was introduced in the VC 1 A May 16th 1995 version. So essentially every SCPH-1000 and SCPH-3000 console can not use the ReadTOC command, it will actually freeze the entire console if you try.

So I was so curious to see what would happen if I booted Dino Crisis Japan, because MottZilla said that what is happening is the game is sending ReadTOC to "unlicense" the CD drive and loose authentication. An important thing to realize about ReadTOC is that it's sole purpose at introduction in VC 1 A is to defeat swap tricks and later for anti-piracy checks. The ReadTOC command is actually the "fix" to stop the audio menu swap trick from working. However the "fix" for the audio menu swap trick didn't actually start working until consoles came with VC1 B CDROM Controller BIOS versions, we think due to an oversight (it works fine on VC1 A).

So to the good stuff, what happens? Well I audio menu swap trick'd Dino Crisis Japan on the SCPH-1000 with BIOS v1.0 and VC0 A September 19th 1994 CDROM Controller BIOS. Did it freeze? NO, it just works. Of course it does, imagine selling a game and someone with the launch Japanese PS1 buys it. What can you do, just freeze their console? That's not good business...

Let me clarify what I believe is going on with the anti-piracy module in this case. The reason the protection is not tripped on vC0 cd controller consoles when using a swap trick in this case is because ReadTOC results in an error so the security authentication process is not repeated. However the game also checks the number of tracks with GetTN and then the position I believe of track 2 with GetTD. So if you did use a swap trick to boot a copy of the game it would trip the protection unless the ToC matched. The version of the Stealth Unlocker he was using during this test was correcting the ToC after the swap occurred so neither the ToC check or ReadTOC caused the anti-piracy module to fail.

Also I believe this version of the anti-piracy module atleast doesn't fail on its check for a non-stealth modchip in this case because it seeks the disc past the SCEx area and then does the SCEx counter check expecting zero codes which is what happens as there is no non-stealth modchip to give a false SCEx code.

So I believe that explains your test result. If ReadTOC worked it would fail, or if they had the SCEx Counter check actually check both the expected response area and the non-expected response area for correct responses. But that would be redundant I guess.

MottZilla wrote: ↑August 11th, 2022, 6:47 am Let me clarify what I believe is going on with the anti-piracy module in this case. The reason the protection is not tripped on vC0 cd controller consoles when using a swap trick in this case is because ReadTOC results in an error so the security authentication process is not repeated. However the game also checks the number of tracks with GetTN and then the position I believe of track 2 with GetTD. So if you did use a swap trick to boot a copy of the game it would trip the protection unless the ToC matched. The version of the Stealth Unlocker he was using during this test was correcting the ToC after the swap occurred so neither the ToC check or ReadTOC caused the anti-piracy module to fail.

Also I believe this version of the anti-piracy module atleast doesn't fail on its check for a non-stealth modchip in this case because it seeks the disc past the SCEx area and then does the SCEx counter check expecting zero codes which is what happens as there is no non-stealth modchip to give a false SCEx code.

So I believe that explains your test result. If ReadTOC worked it would fail, or if they had the SCEx Counter check actually check both the expected response area and the non-expected response area for correct responses. But that would be redundant I guess.

Thanks for the clarification! I assumed ReadTOC was not being sent at all because on your CDROM Debugger it would lock up the console if sent on VC0 which does not have it. Makes sense.

Technically one can get the correct TOC data using a swap trick so in theory the entire protection still falls apart with only a swap trick. There is a variation of the audio menu swap trick where you swap the disc while the TOC is being read (which is a downgrade compared to the swapping after the disc is stopped UX wise). Also it is possible to hot swap after the SCEX data is read on boot but before the TOC is read. This is all again much easier to do anyways on VC0 B consoles because they only require a single swap on boot or can just use the modified audio menu swap trick (because again they don't have read TOC). It's like a perfect storm, where everything that could go wrong with the anti-mod protection did indeed go wrong and it doesn't work like it should if the user manages to do everything right.

For our artificial swap trick made in Tonyhax International and the changes done in the older Stealth ROM build I was testing (stealth ROM build is not public yet that fixes the TOC on 1000/3000/early 3500 consoles) it also corrects the TOC so it's interesting regardless that nothing further needs to be done to defeat the anti-mod check on Dino Crisis for VC0 B consoles.

All of this info was also known at the time publicly, I wonder if anyone ever put all of it together. The original swap trick guide was written in 1996.

Some game programmers were clever and they would actually read the BIOS region to know if you were running on another system

Shadow wrote: ↑September 5th, 2022, 6:02 pm Some game programmers were clever and they would actually read the BIOS region to know if you were running on another system

So far I haven't found a game that triggers the AP screen on stock SCPH-1000 or early SCPH-3000 consoles if the TOC data is correct. Even Spyro YOTD. This is actually how https://alex-free.github.io/aprip works, by simulating the lack of the ReadTOC command for all consoles.

An AP-patch of Spyro YOTD might also trigger the additional anti-piracy measures if one was implemented.

masterg0r0 wrote: ↑November 24th, 2022, 7:37 am An AP-patch of Spyro YOTD might also trigger the additional anti-piracy measures if one was implemented.

I would think so, I haven't actually tried to see what would happen. But that's the beauty of VC0s

Yes. Spyro YOTD has tons of checksum checks in its code to check whether the memory was modified.