Image = decompress(f.read(stream_compressedsize))Īssert entry_sequencenum > prevsequence, 'Sequence numbers are out of order.' If not isdir(outdirpath): makedirs(outdirpath)Įntry_size, # i don't load the entry into a buffer so this is unused O.write(pngchunk(b'IDAT', compress(idata))) + pack('>I', crc32(chunkname + contents))ĭef makepng(image, width, height, outputfile): # values i didn't understand (and didn't need) are named u#. # replace it with your own 32-bit color palette this is just a greyscale placeholder PALETTE = tuple(bytes((x,x,x,0xFF)) for x in range(256)) # neither are filenames, but there are sequence numbers. # decompressed streams result in an 8-bit image dimensions are provided outside of the stream. from sys import argvįrom os.path import join, split, splitext, isfile, isdirįrom zlib import compress, decompress, crc32 Here's a Python script in less than 100 lines that will extract your archive.Įdited to use sequence numbers instead of file count as filenames they will now have the same filenames as in your rip. I didn't even read the code it's simple enough to just look at in a hex editor. You might be able to figure out the uknowns by comparing multiple PAK files.Įdit: changed to all int's after /u/Ooqat comment You should be able to split and extract all the files with this information. Zlib compressed files until end (the x character at the start of each file indicates zlib)Įach file starts at file offset + header size. If you can't figure it out I think this is what the file is like after a quick look:Ĩ byte header (dont know what it consists of) After that I suggest looking at the compression part of this site: I suggest looking at these numbers and what they might represent. If you look at the start of the file there is a repetition of numbers with minor differences each iteration. I used Quake's PAK files to teach myself about this, even though this PAK file is quite different the start of this file looks a lot like the end of Quake's PAK files. It's possible to take these files apart without the source of the program. If anyone has suggestions on how I can proceed with reversing the process that would be greatly appreciated.
I have tried accessing the files using multiple applications with no luck (MultiEx Commander, Game Extractor, etc) The app is written in C++ and uses zlib and libpng. pak conversion process is here (Function - gfx_make_pak - ) pak format, the source code for the application, and examples of the finished.
The good news is I have compiled examples of the original files, the application that converts it to the. PAK files but it has proven to be more difficult than I originally expected. I am working on extracting game assets from.
0 kommentar(er)
