To avoid copyright issues I guess I'd better not mention its name, if you may excuse me.
The cache files generated during playing is encrypted, maybe with a custom encryption.
Here's the file structure of the encrypted cache files:
Code: Select all
Offset Size/Type Specification
0x0 0x10 ID String/Magic Number Sequence
0x10 LONG Header Size(always = 0x400 bytes)
0x14 LONG Format/Encryption Version
0x18 LONG Encryption Flag(1 = encrypted)
0x1C 0x10 Unknown(related with the KEY)
0x2C 0x10 Unknown(related with the KEY)
0x3C 0x3C4 Padding to 0x400
0x400 BYTE[] Encrypted Data(whose size = the size of the audio file to be encrypted)
What is interesting is that the key used for the encryption of the same audio file seem to be different every time its cache file is generated.
And I'm pretty sure that the encryption key is hidden in the cache file and have something to do with the 0x20 bytes from offset 0x1C on.
The conclusion is based on the following experiments:
1. Use the player to generate a couple of cache files of the same music;
2. Exit the player, and cut off the network, and open the player again;
3. Replace the lastest cache file with a previously generated one and the player can still play that music correctly;
4. Replace the above cache file with other cache files generated from step 1, and the results are the same as the one in step 3;
5. Replace the 0x10 bytes from offset 0x1C or 0x2C on of one of these cache files with the corresponding 0x10 bytes from another one among the rest, in both cases the player failed to decrypt the file;
6. Change the modified bytes back and it worked again.
Here are some sample files:
Piano Sonata No.11
Notes:
·folder structure
/plaintexts/ -- contains an mp3 file of the music
/ciphertexts/ -- contains 3 cache files of the same music generated at different moment
·hexadecimal filename -- MD5 digest of the mp3 file/plaintexts