Had to register for this post. First of all thanks for everyone sharing related information, its really helpful when you don't have to replicate every step from the beginning by yourselves.
I have a DEX PS3 on which I've been able to debug the game. The main goal would be to allow custom songs one way or another. I haven't looked at all into any of the online content / downloaded songs, so skip this post if its your only interest.
However, I have quite a PS2 collection which I've been playing through the disc swap feature. As you probably know, some of the latest PS2 versions include an encrypted PAK_W.PAK file. This file is read during the disc swap on PS3 game, with disassembly showing some hints to "PS2_DISC_TRUST". Information on various forums mentions also that the melodies files (.chc) are encrypted on the latest versions of PS2 using "standard" Tiny Encryption Algorithm (TEA) with 32 rounds. I don't have any experience on those as I don't own a disc with these. However it might be possible the PAK_W.PAK is encrypted using a similar algorithm and I think a method to find .chc keys exists, though not public. If anyone has information on this, please PM or better yet publish the method if legally allowed.
Now the interesting part: PS3 checks the whole PS2 disc for any changes. Changing one byte in any file will result in "Not a SingStar disc" error. I've disassembled and debugged this somewhat: the check data is included in PS3 itself, probably in LegacyPS2Discs.pkd. It seems like this file includes all previous releases of PS2 discs in archived format, probably similar to .pkf files (ZLIB?). Of course it is also encrypted as well. However I've been able to dump some of the content related to this check by pausing the game at start of the check routine with a debugger (using breakpoints), then dumping the RAM through webMAN MOD. There is probably a folder structure with folder names being title ids ("SCESxxxx") containing probably a file named "trustdata.xml". The same information can also be found by disassembling the game ELF. The RAM dump revealed some of the contents of this trust check as well, it is probably a file in the following format (Could someone confirm if it is ok to post this? I've removed any critical information for now)
Code:
<?xml version="1.0" encoding="UTF-8"?>
<PS2_DISC_TRUST xmlns="http://www.singstargame.com" xmlns:ss="http://www.singstargame.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.singstargame.com http://lon01-singsql/xml_schema/PS2DiscTrust.xsd">
<TRUST_DB_VER=x>
<DISC PRODUCT_CODE="xxxxxxxxx" SYS_VER="x.xx">
<FILES>
<FILE>
<FILEPATH>PACK_EE.PAK</FILEPATH>
<SIZE>xxx</SIZE>
<POSITION>0</POSITION>
<HASH POS="0" LEN="xxx" TYPE="Whirlpool">hash_here</HASH>
<HASH POS="0" LEN="xxx" TYPE="Whirlpool">hash_here</HASH>
</FILE>
</FILE>
<FILE>
<FILEPATH>songid\movie.ipu</FILEPATH>
<SIZE>xxx</SIZE>
<POSITION>xxx</POSITION>
<HASH POS="0" LEN="xxx" TYPE="Whirlpool">hash_here</HASH>
<HASH POS="xxx" LEN="xxx" TYPE="Whirlpool">hash_here</HASH>
</FILE>
...
The original file hashes match with what I can calculate from the offsets and lengths given in the file for a specific file using Whirlpool algorithm so we can quite reliably assume this is the method used to check the disc. I've tested this by loading a PS2 game with single byte modification to PACK_EE.PAK and the hashes found at RAM dump were the same as before, meaning they come from the PS3 game and are not the ones calculated for the files. However I manually poked the ram to insert my new modified file hashes in place of the loaded ones and
BOOM, THE GAME LOADS THE DISC WITHOUT ERRORS.
I also suspect that PAK_W.PAK contains similar file which is used instead of the built-in trustdata if found on the disc.
Another interesting thing is that the game checks manually for the SingStar Bollywood, you can find the SC-code related to it in the disassembly. This is a PS2 disc that wouldn't load using the disc swap feature, at least that is all I could find from the forums. I don't have the game so I can't find what the ID is used in the PS3 for, but it is interesting to find it in the disassembly. Perhaps this is a feature to block the disc or a fix included by Sony in some update to allow for it to load?
Anyway the next step would be to find the encryption method and keys to PAK_W.PAK or LegacyPS2Discs.pkd, unless someone can create an automatic patch for the RAM during the disc loading phase. Any ideas, anyone?
