xdanieldzd/Scarlet

Nonstandard GXT in Vita YU-NO (no magic)

Closed this issue · 9 comments

GXT files in PCSG00567 (YU-NO: Konoyo no Hate de Koi o Utau Shoujo) are nonstandard, not having a GXT0 magic (from bg.mpk, system.mpk, etc.) .

https://s14.postimg.cc/y6r1lfvo1/nonstd-xtg.png

There seems to be some encryption going on because the files are not compressible with 7zip and rar (low entropy). There's no obvious value matching the filesize either. On the other hand, other file types (from script.mpk, se.mpk) in either basegame and patch v1.02 are extracted without issue (usable .scx files, .at9 files with RIFF header).

Using the same tools (sg-unpack or arc_unpacker), I can unpack mpk's from steins;gate 0 vita, and they yield standard gxt files.

Would you mind having a look?

0x78 0x9c is the zlib header, have you tried using zlib's inflate()? Any chance you could provide one of the .mpk files?

Thanks for the suggestion.
I have processed one of the textures through ALuigi's comtype_scan2 and algorithms 167 and 170 (COMP_UNZIP_DYNAMIC and COMP_ZLIB_NOERROR) are perfect matches. When I run the result through ScarletTestApp, it successfully produces a png file.

So, I suppose it's not zlib's deflate, but close enough, it's compress.

import zlib

with open('yng_h01.out', 'wb') as out:
    with open('yng_h01.gxt', 'rb') as f:
        out.write(zlib.decompress(f.read()))

If you need a sample (pkg is a 500+MB download):

$ wget http://gs.ww.np.dl.playstation.net/ppkg/np/PCSG00567/PCSG00567_T5/306abb42452f0f19/JP0745-PCSG00567_00-YUNO000000000PSV-A0102-V0100-ae38923c80302f3f4b636ad9aa83f2aaf5488a25-PE.pkg

$ ./pkg2zip -x JP0745-PCSG00567_00-YUNO000000000PSV-A0102-V0100-ae38923c80302f3f4b636ad9aa83f2aaf5488a25-PE.pkg "<zrif_string>"
where <zrif_string> is obtained from the NPS database.

$ ./psvpfsparser -i patch/PCSG00567 -o PCSG00567_v102 -z "<zrif_string>" --f00d_url cma.henkaku.xyz

I'll have a look around regarding zlib and C#, ex. if .NET already provides support for files compressed like this, or otherwise what wrappers might be available, so as to add support for decompressing these into Scarlet.

I think System.IO.Compression.DeflateStream might do the trick but I need to get one of those files first to see if it works...

Here's what I can come up with:

// "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Roslyn\csc.exe" dezipGXT.cs

using System;
using System.IO;
using System.IO.Compression;

namespace Misc {
    class Program {
        static void Main(){
            string path = @"album.gxt";
            var decms = new MemoryStream();
            using (var inputStream = new FileStream(path, FileMode.Open, FileAccess.Read))
            {
                inputStream.Seek(2, SeekOrigin.Current);
                using (var decompressionStream = new DeflateStream(inputStream, CompressionMode.Decompress, true))
                {
                    decompressionStream.CopyTo(decms);
                }
            }
            // Do something with MemoryStream, such as toArray(), Seek() to beginning, etc.
            using (var outfile = new FileStream(@"album.bin", FileMode.Create, FileAccess.Write))
            {
                decms.WriteTo(outfile);
            }
        }
    }
}

I ended up working on this as well and also got data decompressed using DeflateStream going, so basic support for MPK archives and at least this kind of compression (i.e. with header values 0x78 0x9C) is now in via commit 7fd596c. It's probably not perfect, but I could unpack system.mpk from YU-NO and get its GXT files converted to PNG, ex. below.

titlechip image 0

Nice! I also started working on this but you were quicker it seems 😁

But I had a different spec for the MPK files, and apparently there are multiple versions with slightly different header fields. The version is in "Unknown06". I will do a PR but I still need to find files of a different version, to test it...

Also, I have no clue down which rabbit hole those commands sent me, but it sure was an amazing trip ;-)

Fixed by 7fd596c. See the related PR #19 for possible MPK field descriptions otherwise.