CPS-2 encryption algorithm has made great progress, overcome in!

The simulation circles around Christmas seem to be cool and cool this year, but the surface is dark. Recently, both Nicola and Andy encrypt CPS-2AlgorithmAfter further discussions, at present, it has been basically clear that the CPS-2 uses a 4-pass feistel network similar to DES, friends who know cryptography must be very familiar with :) from the perspective of password analysis, it seems that the encryption strength is less than des (it may be because the implementation cost of Rom encryption and decryption is 16-pass); until yesterday, nicola has given a specific way to solve the key substitution/selection function (S box), and even Raz of CPS2-Shock cheered for this victory in a specially updated way, it seems that success is not far from success. However, their analysis work has not been completed yet. Although the algorithm is clear, the key analysis work is just getting started, so we still need to wait patiently. The following describes the progress of relevant algorithms:

1/8/2006
Nicola finally figured out the relationship between the address and the key. He guessed that the entire algorithm flow would be: 16-bit addresses and 96-bit keys going through the first feistel network to get the 16-bit key; then the 16-seat key, 16-bit secret, and another 96-bit key are passed through the second feistel network to obtain the plaintext. Nicola has confirmed the first FN, which is also a 4-pass FN, and determined that if the S box in the first FN can be successfully determined (sooner or later ), then he can not rely on any known table (obtained from Charles MacDonald, but the obtained method is unknown. The XOR table given by Raz may also be one of the important references), complete the ROM decryption from scratch! However, the two 96-bit keys currently used are still from known tables. That is to say, based on the current knowledge, for games with known tables, it is not difficult to use a real decryption method, but for games that do not have any known tables, two 96-bit keys still do not know how to find them, he may be thinking about how to use differential password analysis to further study this issue... continue learning.

1/10/2006
Nicola has submitted the obtained algorithm source code to mamedev. The S box in fn1 is still said to be inaccurate, but it is already getting work. Take a lookCodeThe DD inside is very interesting, for example, the CPS-2 uses the hardware watchdog, encryption/decryption is for opcode rather than for data, but also must be combined with the opcode current command address to consider and so on; the general process of opcode decryption is: first, solve the seed according to opcode address and key1 through fn1, then extend the seed to sub-key, and then use sub-key and key2 for XOR, finally, the opcode plaintext is obtained by FN2 according to the result and opcode... it's a good deal, but it's still clear. Nicola guessed that key1/key2 may be exported through the opcode in the hardware watchdog call command, but he hasn't provided a clear method yet. Take a closer look, and pick up the knowledge of FN...

1/13/2006
Nicola provides a brute-force Cracking Method for key1/key2. The bad message is that this method of obtaining keys can only be used for games with known XOR tables (that is, known plaintext; the good news is that multiple key pairs are obtained through brute-force cracking. Nicola found that there is a strong correlation between key1 and key2. They may all be replaced by the same key, nicola expects to use this correlation to find an effective way to further correct the S box in fn1. Now the question is, where should we find these two keys for games that do not obtain the XOR table? Maybe the relationship between key1/key2 can leak some clues from it; maybe this is not a problem at all, because the CPS-2 game has been XOR crack with few left.

1/15/2006
Nicla found that 96-bit key1 can be exported using a 64-bit key master_key, which modifies the decryption process, the process is roughly: master_key (64) is known and extended to key1 (96); a seed (16) is calculated through fn1 (key1, opcode address ); then, seed (16) is extended to subkey (64), subkey (64) is extended to key2 (96), and plaintext is obtained through FN2 (key2, opcode ciphertext. It can be seen that for each different opcode address, key2 is not the same... this is the most tricky nature of the CPS-2 encryption algorithm, but master_key and key1 are always fixed. Nicla further corrected the S box in fn1. He also pointed out that the opcode In the watchdog Call Command has nothing to do with master_key, he guessed that there was a total of 128 bits in the ram of the encrypted device maintained by the suicide battery in the CPS-2, of which 48 bits were watchdog call instructions, 16 bits were encrypted address ranges, the remaining 64-bit is the master_key of the game. So far, Nicola has obtained the master_key of most games through brute force attempts, but some games still cannot obtain the master_key because there are not many samples (I .e. ciphertext and plaintext pairs, nicola has not yet come up with any good solutions to overcome this difficulty. Honestly, I'm more interested in how Andy determined the FN method, but... why does Andy use Spanish to write his blog ?..... I was depressed again.

1/17/2006
Nicola obtained the master_key of most CPS-2 games with XOR files in brute force cracking mode, he pointed out that to effectively crack a game for the same address, there must be at least 7 (E, D, a) triplet. e is the ciphertext of the operand, and D is the plaintext after the XOR operation. There are still some games that cannot obtain the master_key because they only have a few (<7) Three tuples with the same address, nicola conjecture may be able to obtain more triplet values through the complementary nature, but this may lead to "false positives", that is, the cracked result is not the real master_key, this requires luck and patience. Currently, there is no effective method to obtain master_key for games that do not have XOR files.

1/22/2006
Experiments have proved that it is effective to apply the complementary nature to brute force cracking. Nicola once again succeeded in obtaining several master_keys, but even so, there are still a lot of games that cannot be cracked in brute force mode, because there are too few single-site triple keys that can be used. Currently, the progress is very limited. Nicola tries to compare the master_key of multiple language versions of the same game, and tries to observe the possible connection between them, however, this method seems to require some imagination and luck.

2/18/2006
Nicola improved the program for brute-force cracking in a table-driven manner. , this greatly improves the speed. He pointed out that every time one (E, D) combination is obtained, the 96-bit key space of FN2 can be reduced by 2 ^ 16 times. Therefore, for a 96-bit key of FN2, only 96/16 = 6 (E, D) can be cracked. The premise is that these (E, D) pairs must be mutually compatible with the corresponding opcode address (that is,, that is, the 17-bit lower of their address a must be the same. The problem is that not all games can find enough qualified (E, D, a). Right, Nicola's progress is very limited on this critical issue, andy also tried a new method during this period, but it also failed. Currently, the efficiency of brute-force cracking programs improved by Nicola is greatly improved. It takes only 15 seconds to crack the ROM of eight known (E, D, a) pairs, it takes nearly one day to crack three (E, D) pairs. After experiencing and overcoming many hardships, both Nicola and Andy were obviously tired and should have a good rest.