Leaderboard

i took a look at the .CB file and managed to crack it. 1. ENC0 / ENC2 are not encryption ENC is short for *encoding*, and the digit is the method number. *ENC0 — stored, no compression.** The CLSS blob follows the 8-byte header verbatim. That is exactly why CLSS / CTRFImageBuffer / IBUF were readable in a hex editor in the first place. The LZSS chunks live *inside* that blob. Every image resource in SSYF.CB is ENC0. *ENC2 — the whole record is LZSS-compressed.** Same bitstream as below, but with no 4-byte size prefix; the decompressed size is the resource size already in the TOC. Only the 20 .SET files use it. 2. The compression Chunk layout "LZSS" | u32 chunk_size | u32 decompressed_size | bitstream - Bits are read LSB-first within each byte — bit 0, then bit 1, … bit 7. - Multi-bit fields are assembled MSB-first — the first bit read is the field's most significant bit. Grammar. - flag bit 1 → literal: the next 8 bits are emitted directly. - flag bit 0 → match: 12-bit ring position, then 4-bit length, length = field + 2 (so 2..17 bytes). Window. - A 4096-byte ring buffer, initialised to 0x00, write pointer starting at 0. - pos is a 1-based ring index, so the copy source is ring[(pos - 1 + i) & 0xFFF]. pos == 0 never appears in a real token. - Every copied byte is written back into the ring at the write pointer, as usual. - The stream ends as soon as the declared byte count is produced. There is no end marker, and up to 2 bytes of zero padding follow. int bitpos = 0; int getbit (const u8 *s) { int b = (s[bitpos>>3] >> (bitpos&7)) & 1; bitpos++; return b; } u32 getbits(const u8 *s, int n) { u32 v = 0; while (n--) v = (v<<1) | getbit(s); return v; } u8 ring[4096] = { 0 }; u32 r = 0, o = 0; while (o < decompressed_size) { if (getbit(src)) { /* 1 = literal */ u8 c = getbits(src, 8); out[o++] = c; ring[r] = c; r = (r + 1) & 0xFFF; } else { /* 0 = match */ u32 pos = getbits(src, 12); /* 1-based ring index */ u32 len = getbits(src, 4) + 2; /* 2..17 */ u32 s = (pos - 1) & 0xFFF; for (u32 i = 0; i < len; i++) { u8 c = ring[(s + i) & 0xFFF]; out[o++] = c; ring[r] = c; r = (r + 1) & 0xFFF; } } } One chunk decompresses to at most 0x20000 bytes. Bigger images are split across consecutive LZSS chunks that concatenate to exactly width * height * 2. 3. The .dds files — CTRFImageBuffer "CLSS" | u32 len | class name, NUL-terminated ("CTRFImageBuffer") "IBUF" | u32 size | u32 (0) | u16 width | u16 height | u16 pitch (= width*2) | u16 planes (1) | u32 flags (0x00100000) | u32 mask A | u32 mask R | u32 mask G | u32 mask B | u8 bits A, R, G, B (e.g. 0, 5, 6, 5) | u8 top bit index A, R, G, B (e.g. 0, 15, 10, 4) then 1..n LZSS chunksThe pixel data is a plain linear raster 4. The .SET files, and exact frame reassembly Once decompressed, each .SET is a serialised CTRFDataSet that names the textures for a scene and gives the blit rectangles — so reassembly is read from the data. "CLSS" | u32 len | "CTRFDataSet\0" | u32 nrec per record: FF FF FF FF | u32 id | u16 namelen | name | payload CTRFTexture u32 | u32 count | count x NUL-terminated .dds names CTRFPictures u32 | u32 npics npics x ( u16 (0x10) | u16 npieces | u16 W | u16 H | u16 ox | u16 oy npieces x ( u32 texture index u16 sx0 sy0 sx1 sy1 <- inclusive source rect u16 dx0 dy0 dx1 dy1 )) <- inclusive dest rect npics x NUL-terminated picture name <- names come after ALL pictures u32Note that the picture names come after all the pictures, The typical scene is 640x480 built from three pieces: 512x480 from the _00 texture, then the _01 texture folded in half to supply the right-hand 128x480 strip. tex0 src (0,0)-(511,479) -> dst (0,0)-(511,479) tex1 src (0,0)-(127,255) -> dst (512,0)-(639,255) tex1 src (128,0)-(255,223) -> dst (512,256)-(639,479)A few sets sSYf_11) store frames at half vertical resolution and give a destination rect twice as tall — i.e. the game line-doubles them. Other record types are present CTRFContainer, CTRFClipperBuilder, CTRFPictureDraw, and TEXT / PICT / ANIM / LIPS / CLIP sections), but none are needed for images. Script attached: kitae_cb.py python kitae_cb.py .CB FILE -o extracted --assemble python kitae_cb.py .DDS FILE -o extracted # loose CLSS/IBUF file kitae_cb.py

I just figured out how to load external files like materials, textures. But absolute path must be set. I also noticed that *.entity is invoked by skeleton if there's any. External dds loading. But there is still one big issue. How are meshes handled. I still didn't figure out how indices reset. Holy sh!t it automatically converts textures to dds in cooperation with my script for textures

The PVR files look to be LZSS0 compressed from offset 8, and one of the files I tested (IMG0088_A) is 512x512 BGRA5551 with DC swizzling. Something like this:

Inspecting the Pet_Snake.bfz file shows that it indeed is a protected ZIP file with legacy ZipCrypto. The game executable is protected by Themida (😒) so I had to dump the running process to perform some analysis. The ZIP password is derived from the archive's resource path. The loader normalizes the separators, gets rid of the filename, takes the final directory component, and finally converts it all to uppercase. The string is then ran through an embedded lookup table and finally the results are all concatenated resulting in the valid password for this particular BFP file. Here is a script I wrote that will automatically generate the proper ZIP password for the given BFP file: TABLES = [ "as89f7d6af98e7f6a9s87f6as98f76asdf8yasuefyae8f7as6ef9ase87fa6se9", "alkjdfLKDFJeofias4894ewfadfklDFJfsafjlasff89a4fhJLKDSfHdf98daf9s", "afoiefajsfiasdf87ysda987dsfvhsdkvhs8dr7vhsdkfghsie4g8hsdfukzDFDf", "faklsjdfiod9f8asdfjKLDFjds9f8jasdklfjsdf9asd8fuseijkasdkHDFKJDf8", "dflkjasdf98asfuyaiufhaos8efhLHFDJSFhasod8fsdfkLDfd9f8aslkejfDLkf", "dkfjapsdoifjas9d8fajsdfiashdJKFSHdfdfaskdljf9sd8fasd89f7asieufa9", ] def bfz_password(package_path): path = package_path.encode("ascii") return "".join( TABLES[i % 6][path[i % len(path)] % 64] for i in range(64) ) def reconstruct_bfz_path(resource_path: str) -> str: normalized_path = resource_path.replace("\\", "/") separator_index = normalized_path.rfind("/") resource_directory = normalized_path[:separator_index] directory_separator = resource_directory.rfind("/") archive_name = resource_directory[directory_separator + 1:] return f"{resource_directory}/{archive_name}.bfz" def derive_bfz_kdf_input(resource_path: str) -> str: archive_path = reconstruct_bfz_path(resource_path) return archive_path.upper() if __name__ == "__main__": resource = "<FILENAME>" logical_archive_path = reconstruct_bfz_path(resource) password_generator_input = derive_bfz_kdf_input(resource) encrypted_password = bfz_password(password_generator_input) print(f"Resource path: {resource}") print(f"Logical archive path: {logical_archive_path}") print(f"KDF input: {password_generator_input}") print(f"Encrypted password: {encrypted_password}") I am taking the Pet_Snake.bfz file as example and I have opened in my tool. You can also open it in any other tool like 7zip, NotePad++, etc... as long as you can get the names of the files inside of the ZIP archive. You simply take any of the names, in this case we take Models/Characters/Pet_Snake/common/pis-basic-jump.face, and paste it in the <FILENAME> placeholder inside of the python script and run it. Resource path: Models/Characters/Pet_Snake/common/pis-basic-jump.face Logical archive path: Models/Characters/Pet_Snake/common/common.bfz KDF input: MODELS/CHARACTERS/PET_SNAKE/COMMON/COMMON.BFZ Encrypted password: 7aejsjajsauk94fjf8afasf9sefskd7f8aDj6fdsud8Lf8ya7odskos8flhps9sdThe encrypted password can then be used as password to extract the data from the ZIP file. I did not yet take a look at the PKN files you've supplied. I am planning on doing this soon.

Working on it... But struggling with decompression via noesis. You need to use BMS first to decompress *.XMD. Or maybe i'll figure out. EDiT: Figured out. Now you don't need to decompress model... Here we go... # Script by h3x3r from inc_noesis import * import noesis import rapi import os def registerNoesisTypes(): handle = noesis.register("Deadly Premonition - XMD Mesh", ".xmd") noesis.setHandlerTypeCheck(handle, noepyCheckType) noesis.setHandlerLoadModel(handle, noepyLoadModel) noesis.logPopup() return 1 def noepyCheckType(data): bs = NoeBitStream(data) bs.read(8) CSize = bs.readUInt() Size = bs.readUInt() Buffer = bs.read(CSize) data = rapi.decompInflate(Buffer,Size) bs = NoeBitStream(data) if len(data) < 20: return 0 if bs.readUInt() != 0x33444D58: return 0 return 1 def noepyLoadModel(data, mdlList): bs = NoeBitStream(data) bs.read(8) CSize = bs.readUInt() Size = bs.readUInt() Buffer = bs.read(CSize) data = rapi.decompInflate(Buffer,Size) bs = NoeBitStream(data) baseName = rapi.getExtensionlessName(rapi.getLocalFileName(rapi.getInputName())) ctx = rapi.rpgCreateContext() Underline = "_" # Main Info Sign = bs.read(4) ResourceSize = bs.readUInt() TotalIndexCount = bs.readUInt() TotalElementCount = bs.readUInt() Unknown_2 = bs.readUInt() Reserved0 = bs.read(20) Unknown_3 = bs.readUShort() BoneCount = bs.readUShort() ShapeCount = bs.readUInt() Unknown_4 = bs.readUInt() Unknown_5 = bs.readUByte() Unknown_6 = bs.readUByte() Unknown_7 = bs.readUByte() Unknown_8 = bs.readUByte() Unknown_9 = bs.readUByte() ElementStride = bs.readUByte() NormalSkinStride = bs.readUByte() Unknown_12 = bs.readUByte() Reserved1 = bs.readUInt() BBoxMin = bs.read(12) BBoxMax = bs.read(12) Unknown_13 = bs.readUShort() Unknown_14_Count = bs.readUShort() Unknown_15 = bs.readUInt() Unknown_16 = bs.readUInt() MaterialDefOffset = bs.readUInt() BoneDefOffset = bs.readUInt() ShapeDefOffset = bs.readUInt() Unknown_17 = bs.readUInt() Unknown_18 = bs.readUInt() UnknownDefOffset = bs.readUInt() Reserved2 = bs.read(16) IndexBufferBaseOffset = bs.readUInt() ElementBufferBaseOffset = bs.readUInt() NormalSkinBufferBaseOffset = bs.readUInt() Reserved3 = bs.read(16) Unknown_14_Offset = bs.readUInt() print("Element Stride >",ElementStride,"NormalSkin Stride >",NormalSkinStride) # Material Info bs.seek(MaterialDefOffset, NOESEEK_ABS) MaterialName = bs.readString() rapi.rpgSetMaterial(MaterialName) # Shape Info bs.seek(ShapeDefOffset, NOESEEK_ABS) for i in range(0, ShapeCount): StrPos = bs.tell() ShapeName = bs.readString() bs.seek(StrPos, NOESEEK_ABS) bs.read(16) Unknown_0 = bs.readShort() BoneId = bs.readShort() Unknown_2 = bs.readUInt() Unknown_3 = bs.readUInt() BBoxMin = bs.read(12) BBoxMax = bs.read(12) IndexCount = bs.readUInt() ElementCount = bs.readUInt() IndexOffset = bs.readUInt() * 2 ElementOffset = bs.readUInt() Unknown_4 = bs.readUInt() Reserved = bs.read(8) cPos = bs.tell() bs.seek(ElementBufferBaseOffset + (ElementOffset * ElementStride), NOESEEK_ABS) ElementBuffer = bs.read(ElementCount * ElementStride) if ElementStride == 20: rapi.rpgBindPositionBufferOfs(ElementBuffer, noesis.RPGEODATA_HALFFLOAT, 20, 0) rapi.rpgBindUV1BufferOfs(ElementBuffer, noesis.RPGEODATA_HALFFLOAT, 20, 8) elif ElementStride == 24: rapi.rpgBindPositionBufferOfs(ElementBuffer, noesis.RPGEODATA_FLOAT, 24, 0) rapi.rpgBindUV1BufferOfs(ElementBuffer, noesis.RPGEODATA_HALFFLOAT, 24, 12) bs.seek(NormalSkinBufferBaseOffset + (ElementOffset * NormalSkinStride), NOESEEK_ABS) NormalSkinBuffer = bs.read(ElementCount * NormalSkinStride) if NormalSkinStride == 12: rapi.rpgBindNormalBufferOfs(NormalSkinBuffer, noesis.RPGEODATA_HALFFLOAT, 12, 0) rapi.rpgBindBoneWeightBufferOfs(NormalSkinBuffer, noesis.RPGEODATA_HALFFLOAT, 12, 6, 3) elif NormalSkinStride == 16: rapi.rpgBindNormalBufferOfs(NormalSkinBuffer, noesis.RPGEODATA_HALFFLOAT, 16, 0) rapi.rpgBindBoneWeightBufferOfs(NormalSkinBuffer, noesis.RPGEODATA_HALFFLOAT, 16, 8, 3) bs.seek(IndexBufferBaseOffset + IndexOffset, NOESEEK_ABS) IndexBuffer = bs.read(IndexCount * 2) rapi.rpgSetStripEnder(0xFFFF) rapi.rpgSetName(ShapeName) rapi.rpgCommitTriangles(IndexBuffer, noesis.RPGEODATA_USHORT, IndexCount, noesis.RPGEO_TRIANGLE_STRIP) bs.seek(cPos, NOESEEK_ABS) mdl = rapi.rpgConstructModel() mdlList.append(mdl) return 1No skin/bones/skeleton. Could be done later...

The BNK files are compressed with XMemCompress. The LZXNATIVE magic starts at 0x7D0. Everything before it is padding. Drop the contents of the 7-Zip archive into the folder with the BNK files and then run: .\decompress_bnk.ps1 Stuntman Ignition.7z

The progress for the Unreal Engine game loader is that the game boots all the way to the Menu and now I'm just implementing a model viewer to debug assets a lot faster Unreal uses the .xbe to load the models and mesh, I haven't implemented the shaders and such yet, just the mesh building

I'm not sure if this is the right place to post this. it's not a help request or anything like that but I just wanted to share the binary template I created for the SF643D .modelgdb format. I made one for the final game (complete with all parameters) and one for the 2010 prototype (incomplete, covering only the geometry structure). SF643D_010Editor_Templates //The size is huge because it contains numerous node options and sub-options, all with specific identification IDs (as far as I recall, mine are 100% correct; I compared them against the .modelgdb.tex versions "original binary-to-text" conversions left behind in the game). //There are some .modelgdb models that contain "Node_Node" structures. These structures consist of matrix values attached to specific geometry IDs; for instance, a model located at the center of the scene might be moved to a different position based on a Node_Node referencing a specific geometry ID. Only about six models actually use this feature the rest simply use the final pose. I wrote a Noesis plugin to load these models, but the way these matrix-based nodes function makes them a nightmare to handle within a tool like Noesis. Consequently, my Noesis plugin is incomplete, and there are still some vertex formats whose structures I haven't figured out yet. This is the kind of format where it's better to build a specialized tool rather than trying to use Noesis. (If there are any errors or signs of amateurism in the template I created, I apologize; it’s the first template I’ve written that is this complex and large.) //If you want to test a sample here SF3D_modelgdb_sample.zip

The .pck is a ZIP file in disguise. However, two things were changed. 1. Every PK signature (50 4B) is written as OD (4F 44). 2. The zlib header byte 78 is written as 02 Plus one structural change: local file headers are omitted entirely. Entry offsets point straight at the raw deflate payload. The .dir and .tbl files are redundant lookup caches. Use the script attached to extract everything/or just the textures. python zpak_extract.py pack_prog_res.pck # extract everything python zpak_extract.py pack_prog_res.pck -o out --verify # + check every CRC python zpak_extract.py pack_prog_res.pck --list # list, don't extract python zpak_extract.py pack_prog_res.pck --textures # dds/tga/bmp/png/jpg only zpak_extract.py

tools should work Rio Tools Final.zip

I decompressed the data with QuickBMS, then you can manipulate it in ImageHeat. The decompressed data has a header of 32 bytes, which includes the image dimensions. I'm not sure if some images use a slightly different format. The swizzle seems to be standard Morton, at least for the ones I tried. Your script probably works, but be aware of rule 17 for using AI to generate scripts.

I see LZSS sign in SSYF.

also trying to get this figured out props were the first thing thanks to you and other forums | World Architecture and UV stuff was insane to get correctly, props rotatet wrong, level mirrored etc uv and lightmaps working (still some missing rocks, prop lighting off and NPCs looking weird) | skybox/backdrop, prop lighting and rotation done edit 19.08.26 got a lot of the missing architecture working | also got water and glass transparency working Also working on NPCs/Characters: edit 21.08.26 still struggling with the character bodies, clothes and accesories are ok edit 02.09.26 getting closer with the faces, also it seems that in my previous extractions i combined low and high poly models (hat placement still off and some tiny holes in the skin) faces and face parts are separate submeshes that are animated

Okie dokie, thank you

Hey Uber. I was planning on uploading the ripped models from Live and Reloaded to models resource. But since you made the script to rip the models and import them into blender in the first place, I wanted to get your word on it first before I do anything.

Btw, format was already covered on the wiki https://rewiki.miraheze.org/wiki/Rage_Software_XFS

I'm struggling because I really want to load the model from the master data, no matter what

OK. So I took a look at the Korean Bubble Fighter executable (after stepping into the ring with Themida (😒) again) you've provided and I saw that it uses SNOW 2.0 Stream Cipher but, with a few Nexon introduced twists. this I used the following C++ implementation of the SNOW Stream Cipher from this GitHub Repository as reference and wrote my own version in Python and added the Nexon induced twists myself. Use the attached Python script as follows: python .\BubbleFighterPKN.py "path\to\pkn\file" I have tested the Python script on the samples you've given me so I hope it will work on the rest of the files as well. I have no idea what your future plans are with this but, I wish you all the best. 👍 BubbleFighterPKN.py

The file attached doesn't match the screenshot - intended file? Based on the 0x80###### uint32's found at 0x1690, that's likely a palette, and 0xC0 appears to where pixel data might start: Yep:

Well I am gathering hashed asset names. Now i know that texture name is described in material file which is referenced in shape info. But not sure how to load external file via that asset name/path in Noesis. Maybe i'll figure out something.

Found the problem. There is variable NormalSkinStride. Fixed! You can try now.

//------------------------------------------------ //--- 010 Editor v14.0 Binary Template // // File: // Authors: // Version: // Purpose: // Category: // File Mask: // ID Bytes: // History: //------------------------------------------------ char Sign[4]; uint32 TotalFileSize; if (Sign == "XPC2") { uint16 ResourceCount; uint16 Unknown_0; uint32 Unknown_1; uint32 Unknown_2; uint32 Reserved[3]; uint32 ResourceDefOffset; uint32 ResourceDataBaseOffset; FSeek(ResourceDefOffset); struct { char ResourceName[16]; uint32 ResourceOffset; uint32 ResourceZSize; uint16 WBits; uint16 CompFlag; ubyte Flags[4]; }ResourceDefinition[ResourceCount]; } else if (Sign == "XZP1") { uint32 ResourceZSize; uint32 ResourceSize; byte ZLibData[ResourceZSize]; }BMS ############################## get BaseFileName basename get FileSize asize get FileExtension extension getdstring Sign 0x4 get TotalFileSize uint32 if Sign == "XPC2" comtype zlib_noerror get ResourceCount ushort getdstring Dummy 0x16 get ResourceDefOffset uint32 get ResourceDataBaseOffset uint32 goto ResourceDefOffset for i = 0 < ResourceCount getdstring ResourceName 0x10 get ResourceOffset uint32 get ResourceZSize uint32 get WBits ushort get CompFlag ushort getdstring Flags 0x4 string Name p "%s/%s" BaseFileName ResourceName if CompFlag == 0 log Name ResourceOffset ResourceZSize else clog Name ResourceOffset ResourceZSize ResourceZSize endif next i elif Sign == "XZP1" get ResourceZSize uint32 get ResourceSize uint32 savepos ResourceOffset string Name p "%s/%s.%s" BaseFileName BaseFileName FileExtension clog Name ResourceOffset ResourceZSize ResourceSize endif

Here is experimental version of dump tool for full version of Battlefield 6. (attached in the end of this post) For almost a whole year now since beta versions it was possible to use my set of tools to get ANY files from it, be that beta or full version. The only problem was "update" folder that was not supported as it is. To get it dumped, you had to move files from update folder to data folder. Each subfolder inside "update" has "data" inside, and you have to move contents to main "data" folder. It does not overlap and work as intended. Now i made this new version which must scan update folder and add data from it. Important change of .INI file is that now game path must NOT include "data" in the end: C:\games\bf6 D:\dump all After dumping, you can use same set of tools from here: bf6_update.7z

Interesting. My tool initially failed, but I have added support for it. Here’s a quick ’n dirty script for decrypting the bundles. Let me know how it goes. 👍 python .\holodreams.py "path\to\hololiveDreams\game\folder" "path\to\folder\for\decryption" # Example python .\holodreams.py "D:\Steam\steamapps\common\hololiveDreams" "D:\Steam\steamapps\common\hololiveDreams\decrypted" holodreams.py

@UZ.- simple .pak unpacker. Extracted data might be compressed i think, need deep analysis, but .png images not compressed unpack.py

Hi @Hazza12555 Thank you so much for your help! It worked perfectly and extracted all the textures without any errors! I hope you have a great day! You’re very smart! Best regards!

The game was built with Leadwerks, and there is no single master password for the archive. The engine generates the password separately for each entry using its filename, uncompressed size, and a fixed mask stored in the executable. I wrote a bit more about it on my blog if you’re interested. 👍 Put the Python script in the same folder as data.pak, then run it. The extracted files will show up in a new data_extracted folder alongside them. lone_water_data_pak_extract.py

What offset are you seeing a DDS subfile in SSFY.CB? Scrolling through it, there are very few regular block patterns, and changing the wrap width rapidly, you can see wavy patterns indicative of variable length compression. Does the exported DDS have a standard DDS header at least (e.g. this)? The "PVR" files are also wrapped in some variable length compression (not PVR standard blocks).

I am not sure whether or not you're still looking for the AES key but, it should be: 5EECA804CF6271E48362AC5AAB8DF19E1B5552DBE8DD24A4B65A2F65CC38E9AA I have been working on a tool that can recover AES keys from various game engine file formats. Your request served as a nice confirmation that I am heading in the right direction. It is still very experimental. It will most likely not see the light of day anytime soon. I have tested this key with my own tool that can handle Godot PCK files and it works. I am fairly certain that this key will work in Godot PCK Explorer as well. 👍

I just figured it out at meet the robinson. It use same skeleton. Here is struct. Alot of unknowns and guess work. float Rotation[12]; float Transform[3]; float Scale[1]; float Matrix4x4[16]; uint32 Unknown_0; uint32 Unknown_1; ubyte Unknown_2; ubyte Unknown_3; ubyte Unknown_4; ubyte Unknown_5; uint32 Unknown_6; uint32 Unknown_7; float BBoxMin[3]; float BBoxMax[3]; float BBoxRadius; char BoneName[16]; uint32 Unknown_8; uint32 ParentBoneId; ubyte Unknown_9; ubyte BoneId; ubyte Unknown_10; ubyte Unknown_11; uint32 Unknown_12; float BBoxMin0[3]; float BBoxMax0[3]; byte Reserved[8];

originally I was but it seemed like a nightmare to do for all the models, so I don't really have a plan to do so anymore, You're more than welcome to upload them yourself, credit isn't necessary but if you do want to give out credits, credit Birdytsc for the unpacker, and me for the script.

Here you go https://reshax.com/topic/344-swuforce-autoit-scripts This is compression algorthm used in some EA games. If you google "refpack tool", you'll find multiple tools supporting this, even in some official EA repositories.

I created my own DLL which uses MS Detours to hook the necessary functions inside of the game executable. The data the hooked functions parse I log to disk and then I ran them through the python script.

Here file structure. It simple archive with zlib compressed data import std.mem; struct FileEntry{ char path[while(std::mem::read_unsigned($, 1) != 0x0)]; padding[1]; u32 compressedSize; u32 uncompresedSize; u32 offset; // zlib compressed data std::mem::Bytes<compressedSize> data @ offset; }; struct MNG { char magic[4]; u32 filesCount; FileEntry files[filesCount]; }; MNG mng @ 0x0;Here simple unpacker mng_unpacker.py Usage python mng_unpacker.py <mng_file> [output_dir]

Solved with IA. Sprites compréssed with LZRW1-KH

looking for an update on where people have gotten so far. Im new to creating mods and am using claude for like all of it but i have gotten cosmetic mods to work. currently working on replacing zaheer with pain/yahiko, the main constraints so far are getting all of zaheers frames matched with pains (time) and also still figuring out the custom line drawing augments (cant get pains cloak to not be str8 up pants yet). i can get pain to match up almost 1:1 on the idle animation if the cloak doesnt go past his waist, i can get the pain cloak to look perfect but it doesnt end up matching the idle animation very close at all. idk what im doing so im having claude test every angle so i know what works and doesnt and can have claude write something up if you guys want, still trying things and im expecting to get the robe and 1:1 idle animation figured out by today. side note, i have a full naruto roster planned out but gotta get the first one done. (his supports will be pain members + konan)

It works! Thanks!!!

Omg thanks so much!!! seeing these models with out the weird filters is awesome! though other chara characters do give errors other than george sorry to bother i sent the CHARA folder fully from the google drive link if you need it!

Ok, in Shinobi it is very similar: Mesh file HMDL; Verts tag XX C0 YY 6C, then 3 floats and 4 bytes padding. Normals: XX C0 YY 68, just one normals tag so no 69, buffer looks like Int32 too. UVs: XX C0 YY 64 and buffer has Floats no shorts. And I did not find that unk tag 62. Now, to find mesh groups there are 4 patters: 03 01 00 01 00 00 00 05 00 00 00 20 00 00 00 00 04 01 00 01 00 00 00 05 00 00 00 20 00 00 00 00 03 01 00 01 04 01 00 01 Shinobi was released in 2002 and Nightshade in 2004 so it seems like Nightshade uses a newer version of the format. I forgot to mention about bytes 00 00 00 17, These bytes appear at the end of a chain of submeshes or a mesh group. They only serve to separate blocks; I suppose the game tells the PS2, "Here's this block, read it, then I'll send you another one." And that makes sense because, looking at the first byte in the tags, it increments, and when it reaches the separator 00 00 00 17, that byte resets to 00. Something like this: Mesh group submesh1 00 C0 YY 6C 01 C0 YY 68 02 C0 YY 64 submesh2 04 C0 YY 6C 08 C0 YY 68 12 C0 YY 64 submesh3 16 C0 YY 6C 24 C0 YY 68 28 C0 YY 64 00 00 00 17 --------End of block. submesh4 00 C0 YY 6C ---- next tag resets to 00(1st byte) 01 C0 YY 68 02 C0 YY 64 submesh5 submesh6 submesh7 00 00 00 17 -------------End of block and end of mesh groupI've seen that separator in other PS2 games, but they're always at the end of a submesh. In this case, it appears after several submeshes because they're very small. All right, that is my research so far. Thanks for reading all this.

Hey, Have you tried to decompress and/or recompress to see if it works or not? I went with SLPM_66447 because I assumed that is what the topic author is using judging by the screenshot. Could I ask you to share a *.pack file from SLPM_66848 or at least some file that has the compression? I will try to get my hands on SLPM_66848 myself and see if there is any difference. UPDATE #1 I have managed to get my hands on SLPM_66848 and can confirm that there was only one minor change to Capcom's YZ2 compressor. I have managed to extract msg.pack from LINKDATA.AFS and decompressed/recompressed the file with the slightly modified script. The original file and recompressed file are identical. YZ2.py

It looks like Fate/Extella also uses the same type of animation that SSD uses (mtb). Since the extraction script isn't compatible just yet, I can't confirm if this import script is compatible either, but the toolset also included a Blender script for importing animations. I'm attaching that here in case anyone is able to make use of it at some point down the line. blender.zip

Try this: Xbt2DDS.zip

Hey! I worked with this format I have a blender addon to import models into blender