good, it will be added in the next version of quickbms

are you aware of other compression algorithms widely used in consoles like this one?

if you refer to the files extracted from the BIN archive, no they don't use lzss and they look even not compressed at all

also this file confirm my theory, the dds starts at offset 0x165 but I can't help more because I don't have the game

why not you just use quickbms for the test? comtype XXX get ZSIZE asize math SIZE = ZSIZE math SIZE *= 20 clog "dump.dat" 0 ZSIZE SIZE where XXX in your case must be nrv2b or nrv2d or nrv2e (try all of them in sequence), although I doubt it's nrv and it's probably lzo1x. obviously the inpu...

it looks like a charset/substitution algorithm, for example in 96_41.pack seems to be located a DDS image at offset 0x40f where 0xd7 is the byte 0x00 and so on.

in the other file instead there are various 0xa4 bytes so if in reality it's a 0x00 means that it's not a fixed charset but a dynamic one.

yes it looks just lzss (although I'm not 100% sure) with the only difference that the initial value of the sliding window doesn't seem to be the classical "space" char but a null one. the following quickbms script does the job: endian big comtype lzss "12 4 2 2 0" idstring LZSS g...

this is NOT a definitive method, I simply told you how I got those 2 files but there is all the rest of the FF archive to figure first

if you watch in 00004015.dat you see a name at offset 0x68 followed by the zlib data, that's the first name of the first dumped file.
the second one is at offset 0x13e

ok, I try. I have used offzip for the job. I didn't know what type of data was contained in the file so I launched offzip in scan mode for checking if there was a zlib block somewhere: offzip -S localized_code_pre_gfx_mp.ff 0 0 and it reported a block at offset 0x4015 so I launched it in scan+extrac...

I simply extracted the first block at offset 0x4015 through a scanning with offzip.
then I opened the extracted file and noticed it had other zlib blocks in it and so I did another scan and renamed the files using the names found in that file before the zlib blocks.

there is a zlib block in the middle which contains the 2 files I have attached.
the rest of the data is unknown, not xor/rot with a fixed byte and if it's compressed it uses an unknown algorithm

if can be of any help, yesterday I tried a bit using an experimental tool I wrote some months (years?) ago which is a collection of the same algorithms used in ffmpeg and is usable with raw data but got no results, ever noisy data even when using the EA algorithms.

scanning both offset and zsize is not a problem (although doing it for zsize is useless, use the whole zsize and you are ok) but remains ever the problem of the bad algorithms that crash with invalid data. for example in zlib and deflate there is absolutely no problem, the result will be exactly lik...

practically zlib (positive windowbits) and deflate (negative windowbits) are the same thing/algorithm, the difference is that zlib adds this 2 bytes header to the compressed data containing some informations like the level of compression used and so on which are stored in these 16 bits (you can chec...