Due to a request from an actual friend (and the fact that any progress on these will benefit more than just MAME) I decided to take another look at the protection issues with these games.
The MCU is on the decapping list, so, eventually (assuming success) it will be decapped, and emulated properly, however, the type of CPU is a completely unemulated one, so even with decap results the process could be quite long, and a previous decap attempt failed to reveal anything useful. With that in mind, knowing roughly how the protection works beforehand will no doubt help in interpreting the results at the very least.
One of the biggest mysteries with them was the format of the external MCU data rom. It has been known for a long time that the games can be romswapped, so everything specific to each game must be in the external roms (including the protection data) but, unlike the later Kaneko games (Gals Panic 3, Jackie Chan, Bonk’s Adventure, Blood Warrior etc.) the format of the MCU data rom was unknown, it was even speculated that it might simple be the entire (encrypted) external program rom for the MCU after the original decap results didn’t turn up what was expected (as it turns out, it’s not, there is definitely internal rom, this is purely data)
The newer Kaneko titles had a simple encryption across the entire MCU data rom, a 0×100 byte encryption table of values to subtract, that looped over the rom. The games would then request the MCU copy blocks of data from the decrypted ROM into the game RAM. Once it was understood (aside from not knowing where 4 tables on Bonk’s Adventure really come from) it was pretty simple.
Despite being earlier, the protection on Shogun Warriors and B Rap Boys is more advanced. (I can only speculate that they dropped it due to it being more complex to program) It still works in a similar way, sending commands to copy tables, and it also still appears to have the math unit (can be used for hit box detection, random number generation etc.) but there are some subtle but important differences when it comes to how the tables get copied, and how the external data rom is processed.
Unlike the later games you can’t simply apply a 0×100 byte table to the entire rom. The rom was very mysterious because parts of it didn’t even look encrypted, and there were clearly variations on an encryption schemes across the entire ROM with no logical start / end points for each block. Andreas had already established that some _very_ old code that had been trojaned out a Shogun Warriors board (in a failed old attempt) could be found in the external rom by applying a 0×40 sized table to a very specific block of data, but beyond that nothing was clear. We were even unable to determine how the location of that block in the rom related in any way to the commands the game was writing.
After a significant amount of work (and a long time after… I first looked at this when the Jackie Chan progres was on my blog here) I noticed a few additional patterns in the rom, and started testing a few things.
Based on a some observations I cam up with a theory that the external rom was structured as a kind of ‘linked list’. The first byte in the rom is the number of tables it contains, followed by some information about that table, and an offset to the start of the next table.
In testing this theory it appeared to be mostly correct, however, I encountered a few hurdles. Some of the blocks appeared to be in a different ‘mode’. The location of the length of the block (and thus the offset to the next block) wasn’t stored in the expected location. It turned out that this ‘length’ parameter can also be offset by another parameter, which is also used to specify the length of an alternate ‘inline’ encryption table.
I put together some code, tested it with both games, and found that I could now split the MCU roms into logical tables, with parameters for each table. In both cases there was an additional 0×1000 sized block at the end, not specified in the table list, and the same on both games. I don’t know what it’s for, and can only speculate that it might be related to the actual encryption tables used somehow.
From this point it became much clearer what the game was requesting. Shogun Warriors made a request to the protection device for command ‘0×19′. With the proper processing of the table it was obvious that this meant table 0×19, which was indeed that initial startup code that Andreas had managed to find before. It also became very obvious that our current communication with the MCU was wrong, and that it could specify multiple transfers in one command.
Unfortunately this is where progress, for now, stops. The problem being that every single one of the blocks of data encoded can have it’s own 0×40 byte decryption table (and additionally some bitswaps?) and for very small blocks, working out an encryption table that’s only 2-3 times smaller than the table being decrypted is nearly impossible without reference data. The ‘key’ specified in the header of each block is simply 1 byte, the decryption tables are 0×40 bytes, and I can’t see any relationship between them nor the previously mentioned 0×1000 sized block at the end.
It’s progress, good progress even, with access to a working board trojaning and simulating the rest of the protection will be _much_ easier with this newfound knowledge, it should also help immensely for processing the decap results. I don’t know which will happen first.
(B Rap Boys shows nothing new because the initial block isn’t decoded, and it might be doing some check on the maths unit too)
