ZenHAX

Quickbms seems to work fine with the -e option on files I tested.
(including 0 ending)
I attached 2 samples I decrypted on my own (have correct key).

Here is crude decompress script I used.

comtype zstd
get NAME filename
string NAME += .dec
getdstring SIGN 3
get TYPE byte
get VER long
get TZSIZE long
get TSIZE long
goto 0x20
set CHUNKS TSIZE
math CHUNKS += 0xFFFF
set REMAIN CHUNKS
math REMAIN % 0x10000
print "%REMAIN%"
math CHUNKS - REMAIN
math CHUNKS / 0x10000

    if TYPE == 0
        comtype copy
        math SIZE = ZSIZE
    elif TYPE == 1
        comtype slz_01
    elif TYPE == 2
        comtype slz_02
    elif TYPE == 3
        comtype slz_03
    elif TYPE == 4
        comtype xmemdecompress
    elif TYPE == 5
        comtype unzip_dynamic   # it's both zlib_noerror and deflate_noerror depending by the game!
    elif TYPE == 7
        comtype zstd
    else
        print "Error: unsupported type %TYPE%, contact me"
        cleanexit
    endif
append
for i = 0 < CHUNKS
get zsize short
savepos OFFSET
clog MEMORY_FILE OFFSET zsize 0x10000
math OFFSET + zsize
goto OFFSET
next i
append
log NAME 0 TSIZE MEMORY_FILE

Yep, it is just that quickbms returns the -72 error code. Otherwise the output is same as the one decompressed with "ZSTD_decompressStream".

As far as I remember even with the -e option the decompressed data of the sample in the first post FootSE_cm408.spk didn't work, but maybe it was a mistake on my side due to all the tests I was doing in that moment

Ah the final decision I have taken about the next version of quickbms is editing the zstd code for removing the 2 occurrencies of "if (srcSize) return ...", so I will be able to use the ZSTD_decompress function (which has multiframe support so it's bad to not use it) and it will automatically work with any stream <= input side

I unfortunately cannot help with this but I thought I would add another ADLD encrypted type that is not able to be decrypted, even with the updated method described by akderebur or with chrrox' script

I've confirmed that most files can be decrypted using the method described here, except some files such as the one attached to this post.

Here you go.
xor key can be between 6 - 8 long.
key was 0x643233316365

Thanks for the fast answer and help!

Edit: Did it also use ZSTD compression? I'm trying to reproduce how you decrypted it and I've yet to succeed.
Since I've encountered many other files that need to be handled differently, I'm trying to edit the script to support them as well.

Edit2: I've added new samples with files that each have a different key (probably different key size too)

I've posted the sample in order to better understand how to find out the xor key, I can't exactly keep relying on you to find the key each time

here is one of them

Oh, everyone did a very wonderful job, thanks a million.
As for the question, what does the file header "FIA" mean?
They're unique texture file? What kind of software can I watch?

fia is aif the file extension.

aif files are texture files. asf ones have both model data and texture data.

You can see how to load the textures here : http://forum.xentax.com/viewtopic.php?f=18&t=18449 . I have also attached a program that extracts the texture data from the aif/asf files. Drag and drop the asf/aif file on the program exe. With asf files that have lots of textures, it is troublesome getting everything by hand.

Model data inside the asf files is also not hard to read/load, but the only problem is the indices for me. I am able to load the vertex and skeleton data, but not the indices. Hoping someone figures out the compression. Chrrox maybe? I think you were working on the model files, right?

Thank you very much. I got a little closer.
I tried adding headers, 50 56 52 03... height = 1024 = 00 04 , width = 512 = 00,02
Open the PVRTexTool, image's still glitch...

I think I need more add data off 768byte header, but I can't.
I saved the image with PVRTexTool, but it looked like they not have a 768 byte header.
I know I'm wrong this, kindly, please one give more shot?

you need to calculate the data offset.
the offset is in the addr tags.
the addr tags have a buffer reference
the offset and size the addr gives is based off the start address of the buff tag the matches its stream id.
the buff tags I have looked at have a stream id of 0 or A so far.
1st buff is normally stream 0 2nd buff is stream A.
so go to the buff tag (most likely 1st one 2nd seems to be used for faces).
then grab the offset in the buff tag and go to that offset from the start off the buff tag(should be the start of the data
(vertex in model files image data in image only)) and then add the addr offset to that.
the ximg tag will give you the texture info (width height and type)
Image Type 0x2F - ETC2-RGB
Image Type 0x31 - ETC2-RGBA
Image Type 0x32 - EAC-RG11

No need to create headers. Just use the "Wrap Raw Data" option of the PVRTexTool with the correct inputs.

The program I attached does what chrrox mentioned automatically, and extracts the texture data. It just doesn't show the image type. Should make things quicker anyway.

here is ida code for triangle info
https://pastebin.com/4z7jijgE
https://pastebin.com/5DHTFcZh

Looking at the index buffer in the asf files, it seems to have high watermark encoding. I have also seen related methods in IDA Pro :

Encode : https://pastebin.com/GAaiiYFY
Decode : https://pastebin.com/VveTuywF

I think it might be a better idea to figure this out first, before moving on to "SimpleLosslessCompression".

Edit : I got it figured out in the end. It was indeed high watermark on top of that "SimpleLossless". Now I think I can finish my tool.

thanks chrrox, akderebur. I understood that.thanks for helpful.

by the way, I tried extract Audio files.
They're have many aac container, I divided them.
The data header is 20 43 41 41 (CAA), and the voice starts offset 600 bytes.
I think they're formats same Heaven x inferno.

other place, these files seem to be called YAMAHA ADPCM.
I added YAMAHA ADPCM header and Playing, very low pitch and noisy audio.
However it seems that it is certainly possible to obtain correct sound. just low pitch and noisy.
play YAMAHA ADPCM audio, use software called Konvertor.

I attached YAMAHA ADPCM audio headers.
YAMAHA ADPCM extension is *.MMF.

Edit:I tried genh. Interleaved DVI 4-Bit IMA ADPCM is worked. but still noisy.

Finally, can now play back audio. CAA file address 0x148 set to 78, playback is possible with vgmstream aac.

However, many spk files (contain audio) can not be decrypted because of different keys.
chrrox, you said that you can use the correct key (0x643233316365), but where should I write it? I can not unpack the banner_TrialSpace_015.

One thing I noticed about slz type 3 not working.
They seem to have the 00 bytes at the end mabee its useless pad data breaking decompressing the files?

Type 3 seems to be a recurring problem lately :
viewtopic.php?t=7328
viewtopic.php?t=2659

I wonder if there is something wrong with the slz3 algorithm in quickbms. Or maybe they changed it slightly compared to older titles?

I think they changed something.
even the tools released by the original slz decompresssion do not work on the chunks.