Godzilla PS3 .pac files

[tyrannojones]

Hey there! Would someone be able to perhaps take a look into these .pac files? Looking for a way to get at the assets inside... It appears to be using a different compression method to the NTSC version of the game, which I find interesting!

https://mega.nz/#F!nZ4V0TqC!sKjWNJu1VTrpkowRTa288Q

[aluigi]

It's the known add_pac format:
http://aluigi.org/bms/add_pac.bms

[Acewell]

viewtopic.php?f=9&t=457

even if you extract the files from the pac they are compressed with what looks like lzs
but this lzs bms script doesn't work on them even though it follows the structure perfectly.

http://aluigi.altervista.org/bms/lzs.bms

and daemon1 seems to have it figured out but has not told how to
http://forum.xentax.com/viewtopic.php?p=125101#p125101

[aluigi]

Keep us updated when the doubt about the compression is solved.

[id-daemon]

and daemon1 seems to have it figured out but has not told how to

I didnt even had a chance to say anything! You expect me to answer in the middle of a night?

[id-daemon]

Ok i had some food, and now I can answer!

This is what I did:

I took the quickbms LZS code, and rewritten it looking at the file data. It was all done correct, as luigi's code describes. So I don't know why script is not working, maybe some endianess issue.

[Acewell]

I didnt even had a chance to say anything!

sure you did, you made that post yesterday in a thread about compression
without saying anything about how you solved the decompression problem!

[id-daemon]

sure you did, you made that post yesterday

You didn't ask me at that time!

[Acewell]

Keep us updated when the doubt about the compression is solved.

nothing definitive, just endianess speculation, is that enough to work with?
i think its just not possible and i'm convinced daemon1 is practicing witchcraft, this is the only logical explanation

[id-daemon]

daemon1 is practicing witchcraft

I'm practicing Zen, not witchcraft

[Acewell]

aluigi, i think there may be a problem with LZS decompression in QuickBMS,
i searched for other scripts and formats that use it and can't find anything
that extracted successfully to compare against though.

daemon1 basically says he is doing nothing out of the ordinary with the LZS decompression
and he is actually using your code translated to a programming language, see here
http://forum.xentax.com/viewtopic.php?p=125188#p125188


this is the error i'm seeing using "comtype LZS DICT DICT_SIZE" in the lzs.bms script

Code: Select all

Info:  algorithm   159
       offset      0000002e
       input size  0x000e3170 930160
       output size 0x0025129d 2429597
       result      0xffffffff -1

Error: the uncompressed data (-1) is bigger than the allocated buffer (2429597)

Last script line before the error or that produced the error:
  35  clog NAME OFFSET ZSIZE SIZE

with this file included in the attached samples
ch01a_00.dae
but the other samples are producing the same error

samples.zip

help me obi-aluigi, you're my only hope!

[id-daemon]

and he is actually using your code translated to a programming language

I used c# instead of c++ Luigi used, because its better for me. Quickbms decompression routine was also surely written in programming language.

If I can help in something more, let me know.

[aluigi]

Well, there is HUGE difference which is clearly visible... there is a 16bit swapping of the data!
In fact if you add "encryption swap 16" before clog in my script it works perfectly.
Now the question is: what bit of the flag at offset 4 says that the data is swapped?

Maybe it works with the endianess of the file? In that case it's a joke to fix it but I want to know if it's sure at 100%

[aluigi]

In the meantime I have updated the script to version 0.1.2 with that modification I said above (all the rest of the script is original).
Maybe in the next version of quickbms I can make the lzs_unzip() code compatible with the current endianess of the script, just to make it automatic without the "encryption" command.

[Acewell]

In fact if you add "encryption swap 16" before clog in my script it works perfectly.

problem solved thank you, i think this is the first time i've seen that used, i learned something new.
this works with "lzs_unzip" but not "lzs", what is the difference between the two?

Well, there is HUGE difference which is clearly visible... there is a 16bit swapping of the data!

where do you see this 16bit swapping

[aluigi]

lzs_unzip and lzs (mppc) are different algorithms.

The 16bit swapping is the part of code after "then reading the whole data block into memory"

[id-daemon]

where do you see this 16bit swapping

Its the simple endianess, like I suspected. When reading every 2 bytes, you read them in different order. Its called endianess.

[Acewell]

Its the simple endianess, like I suspected. When reading every 2 bytes, you read them in different order. Its called endianess.

right, but i don't know C, C++ or C# programming languages, only the bits that look like python.

this is what i was hoping for when you posted your source, that someone else could spot
the difference between your code and the capabilities of QuickBMS and the bms script.

i'm a bit confused about why the endianess (big) didn't take from earlier in the script though,
unless "lzs_unzip" only decompresses little(?) endian by design or something

[aluigi]

Regarding the endianess I'm quite sure that the difference is in the code used by the developers and the one used in quickbms (not written by me).
In the former they have probably just used value=(16bit)data which means that the endianess of that value is dependent by the one of the system while in quickbms it's forced in little endian (data[0] | data[1] << 8).

Why this has not been spotted before?
Simple, the available samples

[id-daemon]

Model tool viewtopic.php?f=5&t=3569