[Ps2][SocomII] .ZDB Archive Extract/Packager

[Cronotrigga]

Recently, I stumbled across the link below, where someone had managed to extract .zdb archives using a program called quickBMS. He was then able to open other archive types and eventually opened game models using blender. This was really great, however quickBMS tends to be a bit glitchy and wouldn't reassemble .zdb archives correctly. I took it upon myself to write some c# code to show how it could be done. So what does this mean? I was able to disassemble the SOCOM II patch. The only issue is that the bins within the patch are compressed. I'm wondering if anyone on this website has any experience with reversing compression algorithms? To anyone interested in this concept I will post a github link for zdb archives. .zed and .zar will be posted this weekend.

https://ps23dformat.wikispaces.com/S...+US+Navy+SEALs

https://github.com/TylerDev905/ZDBAr.../ZdbArchive.cs

[Pyriel]

When you say "reversing compression algorithms", is that just generally asking about decompression and compression, or does it mean you already figured out the decompression, and you're not sure about how to reverse that process? Just trying to gauge how much work has already been done.

[Cronotrigga]

When you say "reversing compression algorithms", is that just generally asking about decompression and compression, or does it mean you already figured out the decompression, and you're not sure about how to reverse that process? Just trying to gauge how much work has already been done.

Basically the patch is called APACHE00.ZDB, inside the patch we have two compressed bin files, ftscore and szseal. If I remember correctly off the top of my head. What I would like to do is be able to figure out how to take a bin and compress it the same way that the games files are. This would allow for model replacements/map editing or even injecting maps from other socom games into socomII. What I'm really interested in though is to be able to reassemble the patch with my custom code embedded inside. I believe that Socom has both the compression and decompression functionality on the disc. So my question is for someone who has possibly done something similar or even the guys who reverse engineered cheat engines in the past. I would like some advice on the subject. Possibly tools or how to figure out what type of compression it is using? Worst case scenario I could get the game to output the file for me but that wouldn't be very efficient and time consuming.

[Pyriel]

I doubt the game has the compression routine, unless it needs it for writing compressed data to the memory card, which would be fairly unusual. It could be in there regardless, but most games I've seen that utilize compression don't have the compression routine because it's completely unnecessary and a waste of memory.

It sounds like you have neither routine.

Looking at the file is a first step. Developers tend to remove any magic values or other markers (versions, etc.) that aren't strictly necessary, but if you're lucky, they'll leave them in. If not, having some familiarity with different compression algorithms may help you identify header information, how the blocks are structured, and so on. That being said, unless you have an inkling of what the decompressed file should be, it can be difficult to work out from the file by itself. Game developers also like to roll their own algorithms a bit, or they use weird variants that you might not find by looking through standard algorithms. So if you can find it, just reverse engineering the decompression algorithm from the executable is often the easiest way in any case where they didn't leave readily identified signatures in the data.

I've done this on a couple of occasions. I'm by no means an expert, but I always preferred finding the decompression routines to trying work out what quirks had been introduced into LZ77 or whatever by looking a the file. The trickiest or at least fiddliest bit was working out the compression algorithm from the decompression algorithm.