alexfree
Developer
Foreword: I've posted about this in other forums, but just realized no post exists here (my favorite forum period)! This is the newest exploit type to date for the PS1. Me and MottZilla were an unstoppable force back then. The only programs to implement this are stealthrom by MottZilla and Tonyhax International by myself. Unirom still remains closed source (the whole reason Tonyhax International exists, even MottZilla was working on a PS1 backup loader alternative at this time until I came out with Tonyhax International).
If you want to support all SCPH-1000 consoles and early SCPH-3000 consoles you need to do this. As a plus, if you do implement this in your soft-mod and those consoles don't have a mod-chip then standard APv1/APv2 protections are useless! This is due to a backdoor that no one back in the day thought would ever trigger. The only protections that are useful on these consoles are EDC and LibCrypt. Tonyhax International applies bypasses regardless incase these consoles are chipped, but I still find that insane. Even Spyro YOTD USA btw...
Time Frame: 2022
MottZilla and I wanted to make a backup/import loader program that would work on Japanese PS1 consoles. The original idea was to buy a Japanese console, implement a backup loader that does an 'artificial swap trick', and have it then send the SetSession(1) command to update the TOC from the real NTSC-J PSX game disc to the backup or import disc. Updating the TOC is important because some games check it as an additional anti-piracy measure. More importantly however, games which contain CD audio need to seek to the audio tracks based on information derived from the TOC. So if you don't update the TOC, you may get game crashes related to 'missing' CD audio track information, silence or static during CD audio playback in-game, or even trip an additional anti-piracy check if the game has that.
At the time we were working on this, UNIROM was the only program which provided this functionality already using the SetSession command for Japanese consoles. I really however wanted to do this myself since UNIROM is not open source and it would be a fun challenge.
Since I really like launch consoles, I picked up a SCPH-1000 console to develop this idea on. MottZilla had developed a 'SwapBoot' program from scratch which implemented the idea, and he tested it on his console and it worked to update the TOC with the SetSession command and an 'artifical swap trick' enabling playing import/backup discs.
I went to test it on my newly acquired SCPH-1000, and... it didn't update the TOC. This was not reproducible at all on MottZilla's end for him with his console, it worked fine. MottZilla and I emailed quite a bit back and forth discussing this. Eventually it got to the point that MottZilla wrote an entire 'CDROM Debugger' program from scratch. It has a menu that you can use to send specific CDROM commands. Some of the options in the menu also send sequences of commands, and you can attempt to boot a backup/import disc whenever you want after sending any CD commands you want to test out.
With all of this, I still could not update the TOC with the SetSession command on my SCPH-1000. So I tried my SCPH-1001 (which is also a really early launch unit). Same problem! How did MottZilla have it work for his console? None of my consoles were working. I tried UNIROM and the function which sends SetSession after an 'artificial swap trick' and same thing, TOC would not update.
At this point, in sheer frustration I began spamming the SetSession(1) command rapidly in the menu maybe 10 times while doing a test in the CDROM Debugger that MottZilla wrote on my SCPH-1001. Then I booted the disc, and... it worked! CD audio playback, on my SCPH-1001. So what was going on?
I tried another game disc with CD audio on the SCPH-1001, the game Dead Or Alive with ~30 audio tracks. I tried the same thing, mashing the SetSession command about 10 times, and then booting the game. It didn't work. I tried the same game disc with CD audio that did work on the SCPH-1001 on the SCPH-1000. It didn't work either.
So why did the first game disc work at all on the SCPH-1001? The only real difference is the game disc that worked was that it has only one audio track.
Eventually It was figured out that the more audio tracks in the TOC, the more times you need to spam SetSession(1) to update the TOC in this way. Older CDROM Controller Firmware versions also require more SetSession commands in general to update the TOC (which is why the SCPH-1000 didn't work with just 10 SetSession commands). But another issue was hit with this. Sometimes, not every audio track would play in the game. What was the problem now?
So there appears to be a threshold amount of SetSession(1) spamming that needs to be done to update the TOC with this method. You need to send a certain amount of SetSession commands (dependent on CDROM firmware version) to even get a TOC to begin updating. And when it begins updating, if there are more then 1 CD audio tracks there is a really good chance that not every audio track entry will be updated! To figure this out, MottZilla updated the CDROM Debugger to display the entire TOC contents in the main menu, so that SetSession(1) could be sent any number of times and the TOC contents could be looked at as well before booting a game disc.
It turns out, with many more subsequent SetSession(1) commands after hitting the update TOC threshold (highly dependent on the CDROM firmware version), you can eventually update the entire TOC and all audio track info.
MottZilla wrote the original SetSessionSuperUltraCommandSmashv1 code. This is how it works:
1) Send a specific amount of SetSession(1) commands back to back in order to break the update TOC threshold. This is a best guess, which sucks reliability wise. The VC0A firmware requires the most spammed command in general to break the threshold. The VC0B takes a bit less, and the VC1A barely needs any to start updating the TOC.
2) Once past the threshold, the number of tracks in the TOC is read. The TOC should be at least partially updated at this point, which still returns the correct number of tracks even though much of the track info is still missing at this point. The function uses this number and checks every TOC entry for 00:00 tracks (which are tracks that have info missing and not updated). Until it finds none of these 00:00 tracks it keeps spamming sequences of SetSession(1) commands back to back. It then does this all over again, checking for 00:00 tracks. Once there are no 00:00 tracks the function exits and the TOC is fully updated.
This worked, but there were 2 problems. It was very slow, and if the threshold was not passed it failed to update the TOC as there is no reliable way to figure out if the TOC started updating or not (at least that we found at the time). And even if you pass the threshold, you need to do quite a bit more spamming after that to complete the TOC update. For example, games with many audio tracks (~50 for Tomb Raider) could take 5 minutes to complete on the SCPH-1001. But on the SCPH-1000 the same game could take 10 minutes. Tomb Raider is an extreme example however, games with ~30 audio tracks took only about 5 minutes on the SCPH-1000.
The SetSession(1) command sets the session number to 1 and updates the TOC. It is really designed for multi-session discs (i.e. change to session 2 on the disc with SetSession(2)), but the TOC updating side effect is the only way to actually update the TOC without re-authenticating the disc and CDROM drive (which stops any swap trick from working).
The VC0A, VC0B, and VC1A CDROM controller firmware versions found in the earliest consoles (SCPH-1000s, early SCPH-3000s, early SCPH-1001s, and early SCPH-1002s) have a bug however that makes the TOC not update with SetSession(1). The bug is that the CDROM controller thinks the TOC has already been updated by the SetSession(1) command so it does not change it (@nocash confirmed this in an email). This bug is fixed in VC1B and higher, the versions found in all later consoles. This is why MottZilla had success and I had confusing failure with the same exact SwapBoot loader using SetSession(1) to update the TOC.
So I ported the SetSessionSuperUltraCommandSmash code from the CDROM Debugger (written with the PSYQ SDK) to Tonyhax, and made Tonyhax International. Which still to this day is the only soft-mod that can properly update the TOC in backup/import discs on SCPH-1000 and early SCPH-3000 consoles (which have either VC0A or VC0B firmware). Although the early SCPH-1001 and early SCPH-1002 consoles also have the bug in the VC1A firmware, they can already be unlocked which negates the need for an artificial swap trick and the SetSession(1) command.
MottZilla had long theorized that somehow involving the SetSession(2) command could trigger the TOC being updated. Nocash also had mentioned in an email before that if you could read the TOC on Session 2 of the disc instead it would work since the bug only applies to the first session. This would however require converting the disc image to a multi-session one, not ideal and I never figured out how to do it.
When there is not an actual Session 2 on the disc and you send the SetSession(2) command 3 different interrupts occur instead of the 2 that normally do with SetSession(1) (which always exists). Instead of INT3->INT2 for SetSession(1), SetSession(2) returns INT3->INT5->INT5, and then the disc stops and the CDROM drive becomes unresponsive due to a seek error because of the non-existent Session 2 that is not actually on the disc (PSX discs are only containing one session).
What I eventually figured out by testing MottZilla's 'send SetSession(2) then SetSession(1)' idea (by mistake, again) was that you can instead do this:
- SetSession(2)
- Wait for INT3.
- Wait for INT5.
- Immediately send SetSession(1), you will beat the next INT5.
- Wait for INT3.
- Wait for INT2.
What happens I think, is that the CDROM drive is told to go to Session 2. It doesn't find Session 2, but before it can make the CDROM drive unresponsive you can tell the CDROM drive to go to Session 1. Session 1 does exist, the CDROM drive goes to it, it notices you are coming from Session 2 and it knows to update the TOC (using a different non-bugged code path) since the session 'changed'.
This works. It takes about 30 seconds, but on every VC0A, VC0B, and VC1A CDROM firmware that has the SetSession(1) bug you can use this instead and guarantee an updated TOC without de authenticating the disc. Much better then 10 minutes.
This new version of the SetSessionSuperUltraCommandSmash is dubbed v2, and the older version v1. It was put into Tonyhax International a long time ago, providing reliability and fast booting for stock launch Japanese consoles at long last.
Nocash has also updated his documentation explaining this bug as well.
This wouldn't have been possible without MottZilla and Nocash. But 28 years later some random internet people finally fixed Sony's bug.
The bug probably wasn't known about for awhile by Sony for a few reasons. No one was using multi-session discs, and it was probably even rarer to use the SetSession(1) command in this way. There really isn't a reason to do this officially, hence the bug that slipped through.
If you want to support all SCPH-1000 consoles and early SCPH-3000 consoles you need to do this. As a plus, if you do implement this in your soft-mod and those consoles don't have a mod-chip then standard APv1/APv2 protections are useless! This is due to a backdoor that no one back in the day thought would ever trigger. The only protections that are useful on these consoles are EDC and LibCrypt. Tonyhax International applies bypasses regardless incase these consoles are chipped, but I still find that insane. Even Spyro YOTD USA btw...
Time Frame: 2022
MottZilla and I wanted to make a backup/import loader program that would work on Japanese PS1 consoles. The original idea was to buy a Japanese console, implement a backup loader that does an 'artificial swap trick', and have it then send the SetSession(1) command to update the TOC from the real NTSC-J PSX game disc to the backup or import disc. Updating the TOC is important because some games check it as an additional anti-piracy measure. More importantly however, games which contain CD audio need to seek to the audio tracks based on information derived from the TOC. So if you don't update the TOC, you may get game crashes related to 'missing' CD audio track information, silence or static during CD audio playback in-game, or even trip an additional anti-piracy check if the game has that.
At the time we were working on this, UNIROM was the only program which provided this functionality already using the SetSession command for Japanese consoles. I really however wanted to do this myself since UNIROM is not open source and it would be a fun challenge.
Since I really like launch consoles, I picked up a SCPH-1000 console to develop this idea on. MottZilla had developed a 'SwapBoot' program from scratch which implemented the idea, and he tested it on his console and it worked to update the TOC with the SetSession command and an 'artifical swap trick' enabling playing import/backup discs.
I went to test it on my newly acquired SCPH-1000, and... it didn't update the TOC. This was not reproducible at all on MottZilla's end for him with his console, it worked fine. MottZilla and I emailed quite a bit back and forth discussing this. Eventually it got to the point that MottZilla wrote an entire 'CDROM Debugger' program from scratch. It has a menu that you can use to send specific CDROM commands. Some of the options in the menu also send sequences of commands, and you can attempt to boot a backup/import disc whenever you want after sending any CD commands you want to test out.
With all of this, I still could not update the TOC with the SetSession command on my SCPH-1000. So I tried my SCPH-1001 (which is also a really early launch unit). Same problem! How did MottZilla have it work for his console? None of my consoles were working. I tried UNIROM and the function which sends SetSession after an 'artificial swap trick' and same thing, TOC would not update.
At this point, in sheer frustration I began spamming the SetSession(1) command rapidly in the menu maybe 10 times while doing a test in the CDROM Debugger that MottZilla wrote on my SCPH-1001. Then I booted the disc, and... it worked! CD audio playback, on my SCPH-1001. So what was going on?
I tried another game disc with CD audio on the SCPH-1001, the game Dead Or Alive with ~30 audio tracks. I tried the same thing, mashing the SetSession command about 10 times, and then booting the game. It didn't work. I tried the same game disc with CD audio that did work on the SCPH-1001 on the SCPH-1000. It didn't work either.
So why did the first game disc work at all on the SCPH-1001? The only real difference is the game disc that worked was that it has only one audio track.
Eventually It was figured out that the more audio tracks in the TOC, the more times you need to spam SetSession(1) to update the TOC in this way. Older CDROM Controller Firmware versions also require more SetSession commands in general to update the TOC (which is why the SCPH-1000 didn't work with just 10 SetSession commands). But another issue was hit with this. Sometimes, not every audio track would play in the game. What was the problem now?
So there appears to be a threshold amount of SetSession(1) spamming that needs to be done to update the TOC with this method. You need to send a certain amount of SetSession commands (dependent on CDROM firmware version) to even get a TOC to begin updating. And when it begins updating, if there are more then 1 CD audio tracks there is a really good chance that not every audio track entry will be updated! To figure this out, MottZilla updated the CDROM Debugger to display the entire TOC contents in the main menu, so that SetSession(1) could be sent any number of times and the TOC contents could be looked at as well before booting a game disc.
It turns out, with many more subsequent SetSession(1) commands after hitting the update TOC threshold (highly dependent on the CDROM firmware version), you can eventually update the entire TOC and all audio track info.
MottZilla wrote the original SetSessionSuperUltraCommandSmashv1 code. This is how it works:
1) Send a specific amount of SetSession(1) commands back to back in order to break the update TOC threshold. This is a best guess, which sucks reliability wise. The VC0A firmware requires the most spammed command in general to break the threshold. The VC0B takes a bit less, and the VC1A barely needs any to start updating the TOC.
2) Once past the threshold, the number of tracks in the TOC is read. The TOC should be at least partially updated at this point, which still returns the correct number of tracks even though much of the track info is still missing at this point. The function uses this number and checks every TOC entry for 00:00 tracks (which are tracks that have info missing and not updated). Until it finds none of these 00:00 tracks it keeps spamming sequences of SetSession(1) commands back to back. It then does this all over again, checking for 00:00 tracks. Once there are no 00:00 tracks the function exits and the TOC is fully updated.
This worked, but there were 2 problems. It was very slow, and if the threshold was not passed it failed to update the TOC as there is no reliable way to figure out if the TOC started updating or not (at least that we found at the time). And even if you pass the threshold, you need to do quite a bit more spamming after that to complete the TOC update. For example, games with many audio tracks (~50 for Tomb Raider) could take 5 minutes to complete on the SCPH-1001. But on the SCPH-1000 the same game could take 10 minutes. Tomb Raider is an extreme example however, games with ~30 audio tracks took only about 5 minutes on the SCPH-1000.
The SetSession(1) command sets the session number to 1 and updates the TOC. It is really designed for multi-session discs (i.e. change to session 2 on the disc with SetSession(2)), but the TOC updating side effect is the only way to actually update the TOC without re-authenticating the disc and CDROM drive (which stops any swap trick from working).
The VC0A, VC0B, and VC1A CDROM controller firmware versions found in the earliest consoles (SCPH-1000s, early SCPH-3000s, early SCPH-1001s, and early SCPH-1002s) have a bug however that makes the TOC not update with SetSession(1). The bug is that the CDROM controller thinks the TOC has already been updated by the SetSession(1) command so it does not change it (@nocash confirmed this in an email). This bug is fixed in VC1B and higher, the versions found in all later consoles. This is why MottZilla had success and I had confusing failure with the same exact SwapBoot loader using SetSession(1) to update the TOC.
So I ported the SetSessionSuperUltraCommandSmash code from the CDROM Debugger (written with the PSYQ SDK) to Tonyhax, and made Tonyhax International. Which still to this day is the only soft-mod that can properly update the TOC in backup/import discs on SCPH-1000 and early SCPH-3000 consoles (which have either VC0A or VC0B firmware). Although the early SCPH-1001 and early SCPH-1002 consoles also have the bug in the VC1A firmware, they can already be unlocked which negates the need for an artificial swap trick and the SetSession(1) command.
MottZilla had long theorized that somehow involving the SetSession(2) command could trigger the TOC being updated. Nocash also had mentioned in an email before that if you could read the TOC on Session 2 of the disc instead it would work since the bug only applies to the first session. This would however require converting the disc image to a multi-session one, not ideal and I never figured out how to do it.
When there is not an actual Session 2 on the disc and you send the SetSession(2) command 3 different interrupts occur instead of the 2 that normally do with SetSession(1) (which always exists). Instead of INT3->INT2 for SetSession(1), SetSession(2) returns INT3->INT5->INT5, and then the disc stops and the CDROM drive becomes unresponsive due to a seek error because of the non-existent Session 2 that is not actually on the disc (PSX discs are only containing one session).
What I eventually figured out by testing MottZilla's 'send SetSession(2) then SetSession(1)' idea (by mistake, again) was that you can instead do this:
- SetSession(2)
- Wait for INT3.
- Wait for INT5.
- Immediately send SetSession(1), you will beat the next INT5.
- Wait for INT3.
- Wait for INT2.
What happens I think, is that the CDROM drive is told to go to Session 2. It doesn't find Session 2, but before it can make the CDROM drive unresponsive you can tell the CDROM drive to go to Session 1. Session 1 does exist, the CDROM drive goes to it, it notices you are coming from Session 2 and it knows to update the TOC (using a different non-bugged code path) since the session 'changed'.
This works. It takes about 30 seconds, but on every VC0A, VC0B, and VC1A CDROM firmware that has the SetSession(1) bug you can use this instead and guarantee an updated TOC without de authenticating the disc. Much better then 10 minutes.
This new version of the SetSessionSuperUltraCommandSmash is dubbed v2, and the older version v1. It was put into Tonyhax International a long time ago, providing reliability and fast booting for stock launch Japanese consoles at long last.
Nocash has also updated his documentation explaining this bug as well.
This wouldn't have been possible without MottZilla and Nocash. But 28 years later some random internet people finally fixed Sony's bug.
The bug probably wasn't known about for awhile by Sony for a few reasons. No one was using multi-session discs, and it was probably even rarer to use the SetSession(1) command in this way. There really isn't a reason to do this officially, hence the bug that slipped through.
Last edited:
