Releasing the tool

Hi there,

I received the Sygnal analyser ten days ago. I'm trying to setup everything to start reading signals. It's easier to say than to do it :))

I plan to release the tool to convert games in very very short time, however the tool at this moment, although it works great, it works with files (10, 20, 30,31,etc. which are inside the CD) rather than with the ISO itself so you need to extarct the files from the ISO, convert them with the tool and use an HEX EDitor to put the content back.

Another feature is that it's programmed with DJGPP

I was thinking about converting it to Visual C++ and make it work with ISOs, but this will eventually delay the release. Should I release it as it is?

Another thing is that if you want to convert a game for a cart that uses less memory (like i.e. SFIII 3rd Strike to work on cartridge of SFIII NewGen), then you need to create 2 cds. The first CD will contain the files 10,30,31,40 and 41 and we will update as normally, then we need to remove these SIMMS, replace them with new ones and make the second update.

After that we move the SIMMS of the second update to their rightposition (Slot 1-->Slot 2 and Slot 3 -->5 and Slot 4-->Slot 6) and place the SIMMS of the first update to the Slots 1,3 and 4.

Notice that in both updates you should have the correspondent SIMM in slot 5 although we will discard it at the end.

As the cartridge hasn't been hacked yet, this is the only way to do it. Actually it will take almost the same amount of time to make the update as with the original. The main hassle is to change the SIMMS.

If you have any comments or would like to help with the conversion to Visual C++, feel free to comment. I will also release the source probably as GPL.

frequency modifier

As I said in previous posts, the Custom SH2 is feeded with a 6.25Mhz clock. and then multiplied by a factor of 4.

According to SH2 specificactions, this should be done by writting a certain value (2 in this case to address H'FFFFFE90). This must be done from the cache memory (H'C0000000 area). Until this is done, the CPU runs at 6.25Mhz. This means that Flash rom is being read at a lower pace until we force the CPU to run faster.

Still waiting for the sygnal analyzer....

knowing the cartridge better

I made a couple of corrections to my previous post. Apparently none of the chips on the CPU board(except the SH2) have any tricky protection-related function and they seem to be used to generate signals for the SH2 which is constantly powered.

The pinout seems to be identical to the one of the SH2(SH7604), so at this moment I can only think of two ways of reprogramming the keys insides.

* One option is that the SH2 can still run code but with a different unknown-factory-set-key. In that case replacing the BIOS allows the manufacturer to execute code that can reset the keys. I can confirm/refute this optionwhen I get the new sygnal analyzer.
* Another option would be a combination of signals to activate a "programming mode", like i.e.put the two keys in the data bus and activate some control pins.

It also intrigates me that replacing the custom SH2 with a standard SH2, doesn't work. Was the BIOS properly decrypted? Are the control signals on the SH2 working in the same way?

Moving forward

I finally received a good bunch of Flash memories and 2 adaptors for these memories, so I can make myself so many tests as I want.

If you have a look at the pictures below, you'll notice that the cartridge is prepared from factory to work with 2 types of flash roms, the 29f400 (located at position U2 of the cartridge ) and the 28f400(located at U5). The one located at U2 has a similar distance between pins as the SH2, which is a nightmare to solder without the proper equiment, the other one in the back side(U5) has a much nicer pinout, which allows me to connect an eprom to it and test many BIOS.See pictures below of front and back side of cartridge. Notice that the tiny sub-pcb on the back side is just fixed with tape.

I have ordered a digital analyzer so I can check by myself if there is real traffic going on between CPU and EPROM. If nothing happens, that would be bad news, as it will mean that the CPU is somehow blocked. However if it can be unblocked by Capcom, it must be reading something, I just needs to find out where.

I send several re-encrypted Bios to some people interested on trying them, they were re-coded with combinations of keys to ffff and 0's, none of them apparently worked, but as I said before, instead of making blind shots, I'd check first if there is real traffic going on.

In one of the many tests that I did, I tried to run the system with a working and non working cartridges.Once I forgot to insert any cartridge and I got the same picture as with a dead cartridge?!? See picture below.

In the meanwhile I have made a small schematics of the cartridge, see picture at the end. Several interesting conclusions can be made:

I have found a QFP144 pinout of the SH2 that provides helpful information about the structure of the system. (actually i'ts a SH7604, more info here: http://www.datasheetarchive.com/indexdl/Datasheet-078/DSAE0065378.pdf)

The Pinout of the the Custom SH2 doesn't match with the pinout of the QFP-144 SH2, therefore replacing it with a standard SH2, won't work at all. Even if.replacing the SH2 was the solution, this.
Replacing the SH2 is something that I don't like much, as replacing SMDs is not available for everyone, so I'd like something easier, like removing the U2 flash and soldering a new one @ U5.

Another interesting thing is that there is a crystal quartz which is feeding the Custom SH2, which is constantly powered. I still don't know why this frequency is being used instead of the 25Mhz to which is supposed to run.   Frequency of crystal is 25Mhz/4 (6.25Mhz), the SH2 can be configured to run using a multiple (x4) of this frequency.


Bottom line: The custom SH2 is more custom than I expected and as the pinout is proving, however if there is real traffic between the SH2 and the Eprom, it would be just a question of trying several keys.
If there is no traffic, I'll have to use the sygnal analyzer and try to find out the real pinout of the whole thing....and that's going to take sooome time. Let's hope chinese post is fast.

Bios+Games ready to test

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.

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.

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.