I finally found where the problem with the BIOS was, it's with a function called cps3_dma_callback which is a bypass to execute the DMAs as the original CPS3 does.
For those who don't know what a DMA is, basically it's a way of copying blocks of data without making them going through the processor and therefore leaving it availiable to make other things. Basically your code, needs to send some instructions to a controller (disk drive, hard disk, CD, etc) and tell them which sector(s) to copy into which region(s) of memory. This controller has Direct Memory Access (DMA) and copies the data without your processor noticing it. When the copying process is ready a flag or IRQ is triggered.
Anyway, Mame is a very complex emulator and it uses a trick to emulate the DMA properly (when a DMA is performed it should bypass the encryption).
I have tried the BIOS with SFIII NG and SFIII-3 and in both works like a charm.
I have now created a full set of the 6 games completely unprotected and a BIOS based on the BIOS of SFIII-3.
Notice that all this is based on the assumption that a suicided cartridge will execute unencripted code.
If this doesn't happen to be the case, my next shot will be to use a signal analyser to see what communication is really going on between CPU and BIOS in a suicided cartridge. If it's reading something probably it will execute something....
I ordered some working and non working cartridges and I'll try to flash the new BIOS in them. Can't wait to have them with me....
more news soon.
Tuesday, August 23, 2011
Friday, August 19, 2011
1 BIOS is enough
Following my crusade against CPS3 protection, I created an unencrypted BIOS, an unencripted ROMSET and an unencripted MAME's cps3.c. I put everything together (it's easier to say that to do) and finally I run it.
Good news is that it works great and ONLY one bios, SFIII NewGen works with all 6 games.
Actually if you check the code when the game is running it doesn't go back to the BIOS (at least I didn't see it), what makes me believe that once it starts running the game BIOS is not needed anymore.
If we press the service button AND select rewrite the game or the graphics, then we'll jump back to the BIOS.
Another interesting thing is that the Service menu is located in the game code, not in the BIOS.
I also managed to remove all protections in this decrypted BIOS and now it takes any code. I still need to remove the Capcom format CD check.
Unfortunately for some strange reason (probably related to the encyrption) this BIOS can only update the char roms, it doesn't update the code.
Another problem, probably originated by the same reason as above, it gives a failure in the SIMM memory check of the BIOS, but only in the SIMMS that hold the code, the rest are OK...needs further checking.
More news soon.
Good news is that it works great and ONLY one bios, SFIII NewGen works with all 6 games.
Actually if you check the code when the game is running it doesn't go back to the BIOS (at least I didn't see it), what makes me believe that once it starts running the game BIOS is not needed anymore.
If we press the service button AND select rewrite the game or the graphics, then we'll jump back to the BIOS.
Another interesting thing is that the Service menu is located in the game code, not in the BIOS.
I also managed to remove all protections in this decrypted BIOS and now it takes any code. I still need to remove the Capcom format CD check.
Unfortunately for some strange reason (probably related to the encyrption) this BIOS can only update the char roms, it doesn't update the code.
Another problem, probably originated by the same reason as above, it gives a failure in the SIMM memory check of the BIOS, but only in the SIMMS that hold the code, the rest are OK...needs further checking.
More news soon.
Tuesday, August 9, 2011
CRCs are history
I start debugging and getting into the program. I don't know the rest of debuggers out there, but at least in my case, debugging is like programming, in the sense that it takes some time to get into the program and be really productive, so you can't just work in sessions of half an hour.
A couple of days later (overnight which is when I usually can work more than 20 minutes without interrumptions) I have found all the CRC checks.
There are a couple of interesting things in the CRC checks.
First is that there are several CRC checks and they go in blocks. Files 30 and 31 have a common CRC so I just need to modify the 31 and the test will go OK for files 30 and 31. The same goes for 40 and 41, 50 and 51 as well as 60 and 61(4 checks in total in the longest game)
Secondi is that files 10 and 20 have an independent CRC so I should change the CRC both in files 10 and 20.
Another interesting thing is that there are only 6 types of cartridges. If the key is the same, the CRC check is the same. The BIOS may change, but the keys and the CRC are the same independently of country and revision.
After that I have modified my c program and now I just enter the input version and the output cartridge and I get all files re-encrypted and with the right CRC. The ISO modifying process is still manual though.
I have done several tests like Warzard/Red Earth running on SFIII New Gen Cartridge or JOJO Bizarre adventure running in SFIII-3 cartridge. I have done many more tests in MAME which work OK but only those two in the real thing.
I have ordered several memories to enlarge my SFIII Newgen board and I'll convert all 6 games for this cartridge which is one of the earliest. This will eventually proof that games can independently of the cartridge model.
In the meanwhile, I'm creating an unencrypted BIOS that will skip all the CRC and CD Checks so that will accept any CD and any CRC Check. If I manage to get this BIOS without encryption(I don't mean with the keys to 0's but just unencrypted) running on a recompiled version of MAME we will be very close to a phoenix cartridge. I'm about to order a socket for the 29F400 so I can reprogramm it many times without the hassle of soldering. If someone has some tips about how to make many tests on a 29f400 eprom please advice.
Expect more news sometime soon.
A couple of days later (overnight which is when I usually can work more than 20 minutes without interrumptions) I have found all the CRC checks.
There are a couple of interesting things in the CRC checks.
First is that there are several CRC checks and they go in blocks. Files 30 and 31 have a common CRC so I just need to modify the 31 and the test will go OK for files 30 and 31. The same goes for 40 and 41, 50 and 51 as well as 60 and 61(4 checks in total in the longest game)
Secondi is that files 10 and 20 have an independent CRC so I should change the CRC both in files 10 and 20.
Another interesting thing is that there are only 6 types of cartridges. If the key is the same, the CRC check is the same. The BIOS may change, but the keys and the CRC are the same independently of country and revision.
After that I have modified my c program and now I just enter the input version and the output cartridge and I get all files re-encrypted and with the right CRC. The ISO modifying process is still manual though.
I have done several tests like Warzard/Red Earth running on SFIII New Gen Cartridge or JOJO Bizarre adventure running in SFIII-3 cartridge. I have done many more tests in MAME which work OK but only those two in the real thing.
I have ordered several memories to enlarge my SFIII Newgen board and I'll convert all 6 games for this cartridge which is one of the earliest. This will eventually proof that games can independently of the cartridge model.
In the meanwhile, I'm creating an unencrypted BIOS that will skip all the CRC and CD Checks so that will accept any CD and any CRC Check. If I manage to get this BIOS without encryption(I don't mean with the keys to 0's but just unencrypted) running on a recompiled version of MAME we will be very close to a phoenix cartridge. I'm about to order a socket for the 29F400 so I can reprogramm it many times without the hassle of soldering. If someone has some tips about how to make many tests on a 29f400 eprom please advice.
Expect more news sometime soon.
Saturday, August 6, 2011
recrypting the code and CRC problem.
It looks like everytime I go further with a problem a new one appears.
If I want to do something worth it, I should get into the encryption of the system.
I search in my old CDs for the old good djgpp :))
I check what Andy did and how this was implemented in MAME's cps3.c and I start programming....
3 weeks later I have a program working that can decrypt the content of all the files in the CD, encrypt them again with another key and save the result.
Apparently only code files 10 and 20 are encrypted, the rest remains as it is.
I change the code of file 10 into my ISO, but again the same shit, a message says that the system can't be updated :((
There should be some sort of CRC check or even worse a CRC/SHA check that will make it really hard to run any other code than the one originally planned to run in the system :((
However this time the error message was around 80% of upgrade process. This should be definitely a CRC Check.
I see only one solution...debug it in MAME.
I get a copy of MAME and start debugging the game. I'm used to debug in CISC processors and this SH2 is RISC. It's really shit to understand something here. CISC is soooo much clear.
After several days I manage to get into it and I find several breakpoints just before the upgrading process. I'll debug it both using my ISO converted to CHD and the CHD for this game.
If I want to do something worth it, I should get into the encryption of the system.
I search in my old CDs for the old good djgpp :))
I check what Andy did and how this was implemented in MAME's cps3.c and I start programming....
3 weeks later I have a program working that can decrypt the content of all the files in the CD, encrypt them again with another key and save the result.
Apparently only code files 10 and 20 are encrypted, the rest remains as it is.
I change the code of file 10 into my ISO, but again the same shit, a message says that the system can't be updated :((
There should be some sort of CRC check or even worse a CRC/SHA check that will make it really hard to run any other code than the one originally planned to run in the system :((
However this time the error message was around 80% of upgrade process. This should be definitely a CRC Check.
I see only one solution...debug it in MAME.
I get a copy of MAME and start debugging the game. I'm used to debug in CISC processors and this SH2 is RISC. It's really shit to understand something here. CISC is soooo much clear.
After several days I manage to get into it and I find several breakpoints just before the upgrading process. I'll debug it both using my ISO converted to CHD and the CHD for this game.
Understanding the CD
I have decided to give a try and check the structure of the CDs of CPS3, maybe I can change the code and get some infinite lives or even better change my system to another game.
After some research I found the Blog of Andy: http://andreasnaive.blogspot.com/2007_05_01_archive.html
If code is encripted, it's gonna be trickier than I expected....
I extracted the files of my SFIII NewGen CD and created a copy of it, file by file, but my board doesn't recognise the CD :((
I have changed the content of files 10,30,31,40,41 with an HEX Editor and it now recognises the CD and starts the game. This means I'm gonna have to use an HEX Editor to change the content of the ISO.
Files 30 and 31 are related to graphics so I'll replace their content with the content of Warzard/Red Earth which seems to run with the same amount of memory.
After finding out how to upgrade the game in the service menu (might not be so easy to find if you have a Jap BIOS) the sytem starts upgrading....
Ploff!!! at the middle of the process, the upgrade stopped and the screen says that I should contact the technical service WTF! :((( Did I brick my CPS3???
I start my system again and it says automatically that I should upgrade the system. I insert my original CD and upgrades back to SFIII New Gen (luckily).
I believe there should be some sort of CRC check. I have to think over how to go next.
The final result of all this, can be checked here: http://www.youtube.com/watch?v=y0cQWXL7Njo
After some research I found the Blog of Andy: http://andreasnaive.blogspot.com/2007_05_01_archive.html
If code is encripted, it's gonna be trickier than I expected....
I extracted the files of my SFIII NewGen CD and created a copy of it, file by file, but my board doesn't recognise the CD :((
I have changed the content of files 10,30,31,40,41 with an HEX Editor and it now recognises the CD and starts the game. This means I'm gonna have to use an HEX Editor to change the content of the ISO.
Files 30 and 31 are related to graphics so I'll replace their content with the content of Warzard/Red Earth which seems to run with the same amount of memory.
After finding out how to upgrade the game in the service menu (might not be so easy to find if you have a Jap BIOS) the sytem starts upgrading....
Ploff!!! at the middle of the process, the upgrade stopped and the screen says that I should contact the technical service WTF! :((( Did I brick my CPS3???
I start my system again and it says automatically that I should upgrade the system. I insert my original CD and upgrades back to SFIII New Gen (luckily).
I believe there should be some sort of CRC check. I have to think over how to go next.
The final result of all this, can be checked here: http://www.youtube.com/watch?v=y0cQWXL7Njo
Breaking CPS3
After the several requests I've decided to open a blog to show my developments on CPS3.
I have decided to post it like in history mode, step by step, so that everyone can see that this was not a weekend job. Expect recent updates at least at the beggining.
enjoy!
I have decided to post it like in history mode, step by step, so that everyone can see that this was not a weekend job. Expect recent updates at least at the beggining.
enjoy!
Subscribe to:
Posts (Atom)