We now have a non encrypted version of the encrypted SFZ program ROM (03). It still needs to be verified and have the non encrypted data merged back in but I can see normal 68000 instructions easily.
 
Gridle visited friday and did some PC communication code. This really helped as Crashtest lives in France and with the CPS-2 equipment here he had no way to test his communication code without emailing it to me. Thanks to Gridle the process has moved on faster then we had expected. For anyone interested it takes an hour to receive a 512k ROM in non encrypted form.
 
Once the ROM is verified checked and double checked it will be passed to emulation authors for you know what. This could still be while off so we will keep you posted.
 
We also got SFZCH running on CPS-2 hardware even though the program ROM's are non encrypted. Graphics were fine although no sprites were displayed or sound heard which was to be expected. This just goes to show how close CPS-1 and CPS-2 hardware actually is.

We now have a way to dump non encrypted program ROM's WITHOUT the need of bruteforcing. This will really speed things up once our software is finished. We also started work on data transfer between CPS-2 and PC but it will be a while before its finished.

I have managed to find and SOLVE another protection scheme Capcom is using on CPS2 boards....
 
The CPS-2 decryption chip stops decrypting information and starts passing it through unchanged after about 10 seconds UNLESS the following 68000 instruction is passed to the processor for execution.
  CMPI.L #$05642194,D0
This instruction must be passed to the processor at least once every 10 seconds to keep the CPS-2 game alive.
Bruteforcing will now be faster and less harmful to the CPS-2 hardware.
 
If your wondering how I managed to work this out then look no further than the Callus patches. While patching SFZCH to add Qsound I came across this instruction many times being used in situations that made no sense, I thought it very strange. Then when I looked into adding Qsound to Rockman I found the same instruction, again being used in a no sense way. I put it down to compiler error at the time but last night it all fell into place.
 
Me thinks someone at Capcom is going to get their hands slapped for leaving such important CPS-2 protection information in non CPS-2 games. (grin)
 
All this means 2 things,

• We no longer need a reset line. Resetting can be removed from the bruteforce loop.
   
• It's very likely that dead CPS-2 boards (suicide) can be brought back to life by placing noncrypted ROM's on them. This will make allot of people happy.

Breakthrough!!!
 
Using software I have written myself which runs on the CPS-2 system we can get the entire program ROM (SFZ) in nonencrypted form. It will even be able to get all 65536 possibilities for every address...
 
Simple memory screen dump.
 
Single address attack screen.
 
Bruteforce attack screen.
  Before the program will work fully (its currently manual) we need to get communication between PC and CPS-2 complete. Finding a reset line on the main motherboard or gameboard would help loads also.
 
This technique works only with SFZ for now but it should be possible to do the same with any CPS-2 game.
 
Please don't expect to see any CPS-2 games showing up in emulators for a long while yet. We still need to get the program finished and then allow it to bruteforce. Im really not sure how long the latter will take but the one thing I am sure of is..
  THE TECHNIQUE IS 100% SURE TO WORK
In other WIP news here is probably the last spreadsheet I'll release now as Ill be spending time on the above.
Latest CPS-2 non encrypted address values (2,158kb)

I have spent my spare time grabbing numbers with the EPROM emulator. Although this is a boring task we now have quarter of all the possible results at address $174.
Latest CPS-2 non encrypted address values (963kb)

No luck yet in finding an exploit using our own program code but with a little effort I have been able to remove the code stopping the retrieval of all values at address $174. Please download the updated spreadsheet below which also has more numbers added.
Latest CPS-2 non encrypted address values (697kb)
One intresting point so far is the fact one value ($235B) is the same encrypted as it is nonencrypted.

The main processor is in fact a 68000 and not any other from the 680x0 family like I mentioned in the last WIP. My silly mistake, I deleted the instruction to place the CPU into supervisor mode by accident.
 
I also corrected a few typos in the latest spreadsheet. Please download it again using the link below.
Latest CPS-2 non encrypted address values

With some help from the MAMEdev I have determined the main processor isn't a 68000, it's another from the 680x0 family. I will know which once opcodes are tried that only run on certain processors in this family.
 
In the meantime here are more numbers pulled with the EPROM emulator to look at.
Latest CPS-2 non encrypted address values

I managed to place a small piece of my own 68k code (non encrypted) into the CPS-2 systems screen memory. To my disbelieve the code ran perfectly on forcing the main processor to execute it, I've confirmed it to.
 
This basically means;

• The 68k CPU runs on standard 68k instructions. Not so custom after all?
   
• Only CPU fetches from ROM are encrypted, fetches from RAM are not.

This makes it highly likely that decryption takes place between CPU and ROM and not inside the CPU itself.
 
I'm now thinking about possible exploits I can use by inserting and executing my own code, I'm still getting numbers using the EPROM emu too, more soon.

I have retrieved more values from the CPS-2 hardware using the EPROM emu. Still no real visible patterns but I have pointed out more numbers of interest.
Latest CPS-2 non encrypted address values

I have retrieved more values from the CPS-2 hardware using the EPROM emu and put it all in a spreadsheet for easy viewing (Microsoft Excel 97). A few numbers are also pointed out as they form a simple pattern which is very good news.... Suggestions anyone?
CPS-2 non encrypted address values
I want to point out that some things are not possible with the way we are pulling info from the board, including;

• Getting non encrypted info from any address space ( $0000, $0002, $0004, $0008, $0010 etc etc). Addresses we can use are limited.
   
• Filling all the encrypted ROM content with #$00 and still get non encrypted values.
   
  note. I have filled as much as I can (95%) but with no effect on non encrypted values retrieved.

It's been going very well ripping information from the game board but there seems to be no visible patterns left by the algorithm as yet ( look for yourself ).
 
Lots more information still to get from the board.

From the testing done so far using the new EPROM emulator we are already able to get non encrypted values for any encrypted value we choose at a set address.

There were some rumours in the past that graphics ROM's were tied to the decryption process. I can confirm this is not true as games fully run with no graphics ROM's on the game board at all.

I have finished the JAMMA test rig and have included a picture for you to see below. Soon we will be able to start our next attack on the encryption, more info soon.
 

Here is the first picture of the JAMMA test rig I am building. I though I'd build the joysticks first as to me they are the hardest thing to get to look and feel right.
 
As you can see this stick still needs the front and base added, once done it's just a case of soldering the wiring and adding the connector and it will be finished.

D-Zine and Malcolm have discovered more information about the game board, basically chip 4E is another 68000 processor. Chips 4B, 7H, 7J and 7M which are powered by the battery are programmable logic controllers with 4B being the place we believe decryption of the program ROM's takes place. The Connector CN9 allows the programming of these PLC's which are booby trapped.
 
See our encryption page for more information.

My current efforts are in finding number patterns in the $00 data I reported in my last W.I.P update, this could take a while but I can confirm I have found what looks like a basic pattern which is TRUE in both Street Fighter Zero and Alpha. This is only for a few bytes at the moment so don't get your hopes up just yet. Finding number patterns is something everyone can do so get comparing those tables and send your findings here.

As said a couple of days ago, I've found $00 data blocks in Street Fighter Zero and Alpha that are encrypted. The largest is block is 150 bytes long with three smaller ones at 82, 50 and 46 bytes. The tables are in report four on the encryption page ( here ). There could very well be number patterns showing in these tables but I haven't had time to investigate this yet. I can also confirm the encryption is calculated on word values.

I've had my first glimpse of how the encryption works. WOW This is big news... I've posted my findings so far to the encryption page, along with another update.

I've discovered and can confirm that new game revisions uses the same variable for encryption (stored somewhere in the game board) as their predecessors. This could have been known to others but we were not aware of it.
 
My research on these ROM's continues... Stay tuned.

Malcolm has discovered that the battery does not power the S-RAM he located, it instead powers 4 Custom IC's labelled 4B, 7H, 7J and 7M.