Rock Band 3 PS3 Network Packet Zlib compression

[hun10sta]

Hey all. Wasn't sure if I should post this in the Network protocols forum or the archive forum. I wound up going with the archive forum as this specifically relates to compression (the actual protocol is just Quazal, nothing special or undocumented).

Rock Band 3 (and The Beatles Rock Band and probably the rest too) use a weird form of Zlib for compression of its network packets that I can't figure out. All the documentation surrounding Quazal says it should just be bog-standard Zlib, but it absolutely is not in this case. I've tried offzip to scan the file for Zlib as well as writing a custom tool to try to decompress it with the Zlib library, and neither worked. Wondering if anyone out there had some potential solutions, if you do, please share so I can continue analyzing this protocol.

I've attached a few sample Zlib blocks from packets. Hopefully someone can help me out.

[aluigi]

I did something on quazal in the past mainly related to the Tincat client-server protocol (just the header) and the rc4 encryption of the packets sent/received from *.quazal.net.
Here the 78 9c is definitely a remainder to zlib but it's not deflate data, or at least not the standard one.
It may be a switch of the 3 opcodes like it happened in daa2iso or some encryption or a different algorithm, can't know without working on it (not in my plans eh eh eh).

[mimak]

Hey all. Wasn't sure if I should post this in the Network protocols forum or the archive forum. I wound up going with the archive forum as this specifically relates to compression (the actual protocol is just Quazal, nothing special or undocumented).

Rock Band 3 (and The Beatles Rock Band and probably the rest too) use a weird form of Zlib for compression of its network packets that I can't figure out. All the documentation surrounding Quazal says it should just be bog-standard Zlib, but it absolutely is not in this case. I've tried offzip to scan the file for Zlib as well as writing a custom tool to try to decompress it with the Zlib library, and neither worked. Wondering if anyone out there had some potential solutions, if you do, please share so I can continue analyzing this protocol.

I've attached a few sample Zlib blocks from packets. Hopefully someone can help me out.

Hi, currently I'm working on Quazal game's packet compression too (25 to Life, quite an oldtimer) and I've also expected standard Zlib algorithm as it's documented for Nintendo games by Kinnay, especially because it indeed is there for Ghost Recon games that I work on as well.
In my case the compression only applies to the data (if you're familiar with Quazal PRUDP stack it's RMC data field precisely) and only to the packets with the length of data above ca. 40 bytes.
In the RMC header I get the length of the uncompressed data - I have no idea why somebody would compress just a part of the data field, but that's what actually takes place.

I've already come through the compression algo cheatsheet but unfortunately that one is not there.
I have two sample payloads attached, first line is RMC header with the second byte being the uncompressed data length, the second line is the uncompressed data and the last one is compressed bytes.
After a brief reversing of the game I can tell that 25TL's algorithm always adds 0x11 0x0 0x0 sequence at the end of the compressed buffer.
By the way, if anyone knows a name or implementation I would be really grateful, it could spare me a bit of time.

Fortunately for the original developers and unfortunately for us, Quazal compression algorithms could be potentially custom.
What they should have in common though is a base class called Quazal::CompressionAlgorithm.
It's a simple interface class that has two virtual methods - CompressImpl and DecompressImpl (in a decompiled VMT they would usually be the 2nd and 3rd function, respectively) that Zlib and all other compression algorithms would implement, including yours. These methods directly compress and decompress buffers.

Unless you have already found a known algorithm that works for you, I would suggest reverse engineering the implementation of CompressionAlgorithm and rewriting the algorithms from decompiled code.
A tip to help you find the base class constructor is that it should contain both "Compression" and "Decompression" strings passed to a two calls to the same subroutine one by one.
You should also make sure the buffers you're trying to decompress are unencrypted, it's usually RC4 (here's an example C# implementation by WarrantyVoider) but whether it's used for packet encryption varies between games.

[mimak]

I've already come through the compression algo cheatsheet but unfortunately that one is not there.
I have two sample payloads attached, first line is RMC header with the second byte being the uncompressed data length, the second line is the uncompressed data and the last one is compressed bytes.
After a brief reversing of the game I can tell that 25TL's algorithm always adds 0x11 0x0 0x0 sequence at the end of the compressed buffer.
By the way, if anyone knows a name or implementation I would be really grateful, it could spare me a bit of time.

Already found it, it's lzo. Found it by characteristical math on constants that it uses, maybe this approach could help you.

[aluigi]

So the packets provided in the opening post were encrypted and it's just a coincidence that they looked like a zlib header, correct?

[mimak]

I think it could be that, Rock Band 3 came out in 2010 while Ghost Recon Online (2012) already used PRUDP payload compression (standard Zlib) and then RC4. Could confirm if I could see the header, these seem to be only the unreadable parts of the packets. Although in all 3 samples there is 0x78 0x73 sequence at 2nd byte it doesnt seem to be just Zlib.
One more thing that I can say is that 25 To Life used standard LZO, so chances that this algorithm was customized have dropped quite a bit just today. I would suspect Quazal used to provide/recommend rather standard compression implementations with their SDK.