CPS-2 Shock

Report Three
I am now going to show you some encrypted data. To do this I will use ROM's from Street Fighter Zero revisions 950627 and 950727. Only one ROM from each game board contains the encrypted data in question, it sits in socket 3 of the game board. I am also going to use the one equivalent ROM from the CPS Changer version of Street Fighter Zero. This game is the same as its CPS-2 counterparts but is non encrypted. If you have the ROM dumps of these games the checksums for these ROM's are;

Street Fighter Zero (rev. 950627) : 844220c2
Street Fighter Zero (rev. 950727) : f5444120
Street Fighter Zero (Changer) : 1140743f

Before I looked at any data from these ROM's they had to be byte swapped. If your going to compare data from this page with your ROM's you must byte swap them before the data here will match up. From now on all references to Street Fighter Zero revisions 950627 and 950727 will be as SFz1 and SFz2, references to Street Fighter Zero (CPS Changer) will be as SFzch. With these details out the way lets make a start.

The data in the table below consists of two hexadecimal dumps from a set location of both CPS-2 revisions only. All data here is encrypted.

         SFz1
         SFz2

$445FC : $4460C : $4461C : 28 1C F3 97 7D DC 41 0C 32 16 22 76 B1 B5 FF 47 BB 6B 01 51 4E 08 DF 0A 48 0B 2B A9 6A 81 D2 C0 41 3D 22 74 80 2B E3 9A 32 33 7C C0 F5 05 C0 56 $445FC : $4460C : $4461C : 3F 64 65 57 52 C9 D0 DF 72 BC 03 8B AB 91 44 72 29 6D 01 51 3F 01 DF 0A 66 1C 11 57 89 D6 91 C1 10 C9 9F C5 B5 23 E2 1E 90 7F 1B F7 32 FC BA 58
As you can see some bytes (marked yellow) actually match in both encrypted sets. Lets move this information to it's correct offsets program wise and compare it with the non encrypted version. I used the same techniques as my first report here to do this. I have also highlighted the encrypted bytes and relevant SFzch parts white so you can see the data above and below matches.

        SFzch
         SFz1          SFz2

09 C0 00 08 00 E1 09 C0 00 08 01 61 09 C0 00 08 01 01 09 C0 00 08 01 21 10 2E 00 04 32 3B 00 06 4E FB 10 02 00 08 00 44 00 4A 00 50 54 2E 00 04 70 00 1D 40 00 0A 1D 40 00 0F 1D 40 00 09 3D 7C 00 00 00 10 3D 7C 00 F0 00 14 0C 2E 00 02 00 03 66 06 3D 7C 00 30 00 14 10 2E 00 03 E5 48 41 FB 00 16 2D 48 00 20 4E 75 4E F9 00 01 33 00 54 2E 00 04 4E 75 4E F9 00 01 3B 2C 00 04 49 C6 00 04 4A 8A 00 04 49 C6 00 04 18 17 00 10 00 05 00 00 00 00 00 10 00 05 00 10 00 00 00 10 00 05 00 20 $445CA : $445DA : $445EA : $445FA : $4460A : $4461A : $4462A : $4463A : $4464A : $4465A : 09 C0 00 08 00 E1 09 C0 00 08 01 61 09 C0 00 08 01 01 09 C0 00 08 01 21 8E 5E C2 3D FE AB F6 DC 7D 88 8C 6B 05 7E AD F9 0B BA 33 0B 69 BF C0 0F 31 3E 28 1C F3 97 7D DC 41 0C 32 16 22 76 B1 B5 FF 47 BB 6B 01 51 4E 08 DF 0A 48 0B 2B A9 6A 81 D2 C0 41 3D 22 74 80 2B E3 9A 32 33 7C C0 F5 05 C0 56 2F 86 82 A8 ED DC 83 E8 D1 6F 5A 6A 35 12 B9 85 AA BD 33 E2 46 6F 3F E7 00 04 46 50 00 04 47 14 00 04 46 50 00 04 18 17 00 10 00 05 00 00 00 00 00 10 00 05 00 10 00 00 00 10 00 05 00 20 $445BC : $445CC : $445DC : $445EC : $445FC : $4460C : $4461C : $4462C : $4463C : $4464C : 09 C0 00 08 00 E1 09 C0 00 08 01 61 09 C0 00 08 01 01 09 C0 00 08 01 21 70 3C 3C F9 D3 9D 45 E4 B0 01 EA 9A DD 07 B7 4C 78 0E 03 F3 8D 0F 94 54 7B 5D 87 14 CF 07 DD C6 CD E5 7E C0 65 5B 50 E6 3F 64 65 57 52 C9 D0 DF 72 BC 03 8B AB 91 44 72 29 6D 01 51 3F 01 DF 0A 66 1C 11 57 89 D6 91 C1 10 C9 9F C5 B5 23 E2 1E 90 7F 1B F7 32 FC BA 58 22 CD DD 5A 25 64 C8 95 8E DA 00 04 46 42 00 04 47 06 00 04 46 42 00 04 18 17 00 10 00 05 00 00 00 00 00 10 00 05 00 10 00 00 00 10 00 05 00 20
What you can see here is $3D $7C from two different locations in the non encrypted ROM falling on address $4460E in both encrypted ROM's, I've marked it yellow. The result of this is bytes in both encrypted ROM's equalling the same. This also applies to $00 $14 falling on location $40612 in both encrypted sets. There are other $3D $7C bytes in the non crypted code but because they don't fall on $4060E they do not equal $01 $51. I've highlighted blue the addresses that can be used to confirm these are the same pieces of code even though encrypted. Please read my first report here to find out how as I'm not going to explain it again now.

Let's take a look at this a little closer. I'll also add the Motorola 68000 instruction that these non encrypted bytes execute.
SFz1

    Encrypted :  $4460E  01 51 4E 08 DF 0A Non encrypted :  $44984  3D 7C 00 F0 00 14         MOVE #$00F0,20(A6)

SFz2

    Encrypted :  $4460E  01 51 3F 01 DF 0A Non encrypted :  $44992  3D 7C 00 30 00 14         MOVE #$0030,20(A6)

What's interesting to note is that one set of double zeros matches ($DF) and the other doesn't ($4E and $3F). This could be due to the encryption working on words rather than bytes, or even where the $00 sits within the 68000 instruction.

I've found other locations where this happens, it is not a one off. This find is the first real clue into how the encryption works, it closes the doors to some ideas and opens the doors to others. This is good news.

This information tells us a very important rule of the encryption.

68000 encrypted instruction values are calculated on the address they sit in ROM memory. This could involve the program counter.