PS3 Hacking the Singstar DLC encryption for backup/custom songs?

[Spoony]

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)

<?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?

Hey everyone,
I was able to successfully extract the LegacyPS2Discs.pkd file using @Edness's tool. The extraction contains what I believe is the whitelist for supported PS2 SingStar discs. This has helped me understand how the game determines which discs are recognized during disc swaps. However, I'm still unsure if I can add/modify the XML files, repackage, and overwrite them to fix compatibility issues.
My Setup:

• PS3 Model: CECHK01 (Fat PS3)
• Custom Firmware: Evilnat 4.91.2 with Cobra
• Region Modification: I have modded my PS3 to be a UK system (PAL region) to test PAL SingStar compatibility.

Issue: Some PAL Discs Not Loading

Despite both of these games being present in the trustdata.xml whitelist, I'm experiencing an issue where:
SCUS97571 (NTSC) loads without any issues.
SCES54570 (PAL) is not recognized and gives a "Not a SingStar Disc" error.
What I've Checked So Far

• Both games are in trustdata.xml, meaning they should both be recognized.
• File structure differences: The NTSC disc uses mus+vid.iav while the PAL disc uses music.mib and movie.ipu.
• Hashes and Verification: The game may be failing the integrity check on the PAL disc, but I'm not sure why.
• Region-based lockout?: Even though my PS3 is modded to be a UK (PAL) system, I suspect SingStar may still have region-based restrictions on PAL SingStar discs.

Questions & Next Steps

1. Does SingStar PS3 have additional region locking for PAL discs, even if they are on the whitelist?
2. Would modifying trustdata.xml (e.g., file paths, hash values, or system version) help force recognition of the PAL disc?
3. Has anyone else experienced this issue with mixed-region SingStar discs on a modded PS3?

Any insights or suggestions would be greatly appreciated! Thanks in advance for your help.

Seeing this post, I made an interesting discovery with my new PS3. I now have one of the same songs as @mattwookie has. Pack0_10000J.pkg.drm is a-ha - Take On Me and the filesizes are different. The filesize in this screenshot is 61369583, my filesize is 61369536 and in my SongCache.xml, the filesize is listed as 61369280.

Does this say anything to the encryption specialists in here? As I understand it, probably can't be AES-128, because some of the filesizes aren't divisible by 16 (the size of the PSID).

I also have a small meta package that links to some Queen songs, Pack0_2000NU.pkg.drm. My file is 5510 bytes (5254 bytes in SongCache.xml), if this could help me in some way.

Hey @dittnamn,
I saw your post about Pack0_10000J.pkg.drm and found it really interesting. I have the PS2 SingStar Pop disc (SCUS97580), which also contains a-ha – Take On Me, and I've already extracted all the files using:

• SS_EXTRACT (to get files directly from the PS2 SingStar disc).
• @Edness's tool (to extract the LegacyPS2Discs.pkd file from the PS3 system).

Since I now have access to the raw files from both the original PS2 disc and the PS3's legacy SingStar database, I'm curious whether I can recreate the DLC version that you have.

My Goal:

I'm working on a way to rip all my PS2 SingStar discs and convert them into DLC, so I can avoid relying on the disc swap feature entirely.

My Theory:

My idea is to package the audio, video, and melody files into a standard .pkg file without the .drm encryption, and hope that it loads—since I've structured everything exactly the same way as a .drm file.
Would you be able to share the directory tree and metadata for Pack0_10000J.pkg.drm? It would help compare file structures, sizes, and any potential differences in encryption or formatting between the original PS2 version and the DLC version.

Thanks in advance! Looking forward to your response.

Hi! Back in July I reversed the encryption algorithm used by SCEE London Studio PS3 games because I needed to for other research/projects, and later on I released it to the public (currently just on ResHax). It supports extracting all of their known PS3 PACKAGE variants.
https://reshax.com/files/file/79-ps3-scee-london-studio-package-extract/

Is the tool capable of repackaging too?

 

[Edness]

Hi! Back in July I reversed the encryption algorithm used by SCEE London Studio PS3 games because I needed to for other research/projects, and later on I released it to the public (currently just on ResHax). It supports extracting all of their known PS3 PACKAGE variants.
https://reshax.com/files/file/79-ps3-scee-london-studio-package-extract/

Is the tool capable of repackaging too?

Not currently, though most of the games appear to be capable of reading the files extracted. For more info on that see here.

Anyway, just as a general update - yesterday I got to work a bit more on the .PKG.DRM DLCs, and have successfully managed to extract one.

When it's done, I intend it to also have a raw dump mode that lets you decrypt/strip DRM/PSID, or re-apply it with a different PSID. But (currently) it doesn't look like the games will let you load them with DRM stripped away. Haven't really tested it extensively yet, though.

 

[Berion]

That's fantastic news for Singstar fans. No longer IDPS spoofing. Fingers crossed and thanks for your time.

 

[Spoony]

@Edness,

I've been digging through the EBOOT.BIN hex dump, and I found some interesting references related to DRM and encryption. There are multiple mentions of .pkg.drm, keys.edat, and even some cryptographic terms like IV_len, key_indicator_len, and selective_encryption. These seem to suggest that SingStar has a layered DRM system, likely verifying song files before allowing playback.

There are also references to MP4IPMPXDefaultData, MP4DecoderConfigDescriptor, and ipmpDescriptorId, which could mean that media files (like song videos or backing tracks) have additional IPMP (Intellectual Property Management & Protection) security tied to them. Maybe that's why stripping DRM from a song file doesn't work outright—the game might still be checking something else, like a signature or another verification layer.

One interesting thing I noticed is that the DRM verification logic might be inside EBOOT itself. If we can pinpoint where it checks for pkg.drm or validates song licenses, we might be able to patch it or trick it into accepting custom content. I'm thinking that the game cross-references something in SongCache.xml or a specific signature stored within the .pkg.drm.

Curious if you or anyone else has looked into how keys.edat is used yet? If that file is crucial, maybe extracting its contents could give us some insight into how the decryption works.

Let me know what you think! Happy to keep testing and sharing findings.

 

[dittnamn]

@Edness has managed to do some big things now, but wasn't able to post here for now. The update is here: https://www.psx-place.com/threads/re-hacking-the-singstar-dlc-encryption.49222/

Now we should be able to at least decrypt the DLC, although there's some work left to add custom songs.