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

Hi! here my beta direct Blender script importer APT__Character_Importer_Blender_5_2_v0_1.zip

yea I sorted it out I do Know the unnamed files are likely Audio files?

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

just checked and yeah the mercedes.exe is the exact same as his, your TruckRace.exe is an InstallShield 2000 installer which I've now added support for but I can't find anything regarding encryption, I've found the LZSS function but also didn't see anything near it

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

I have some encrypted ones from "Mercedes-Benz Truck Racing". Here you go: SYN_SAMPLES.zip

LZSS compressed use script to extract content from SYN files from this game syn_extract.py needs Python 3.6+ whole tree - walks *.SYN recursively python syn_extract.py mercedesbenztruckracing_syn extracted one archive; output dir defaults to "extracted" beside the input python syn_extract.py Textures/Textures.SYN explicit destination python syn_extract.py Cockpit/Textures/Textures.SYN /tmp/cockpit-tex syn_extract.py

Thank you for letting me know! I will look into it. 👍

@Falkrian Just tried your script on the Chinese (2011-04-11) & Korean (2026-05-08 & 2025-12-17) version but it doesn't seem to get the key right, the version I'm working with can be found on archive.org (don't wanna link it cause anti piracy rules and stuff) Config0000.zip

Also fun fact - some passwords in older engine versions are stored as plaintext in game executable xd Some examples: Leadwerks Engine - Furious Frank Demo (PC) Leadwerks Engine - Last Chapter (PC) Leadwerks Engine - LE2 qBoids (PC) Leadwerks Engine - Swords and Skellies (PC)

from inc_noesis import * import noesis import rapi import os def registerNoesisTypes(): handle = noesis.register("Taxi Racer New York 2", ".dct") noesis.setHandlerTypeCheck(handle, noepyCheckType) noesis.setHandlerLoadRGBA(handle, noepyLoadRGBA) noesis.logPopup() return 1 def noepyCheckType(data): bs = NoeBitStream(data) if len(data) < 20: return 0 return 1 def noepyLoadRGBA(data, texList): bs = NoeBitStream(data) baseName = rapi.getExtensionlessName(rapi.getLocalFileName(rapi.getInputName())) bs.read(31) PixelFormat = bs.readUByte() MipMap = bs.readUInt() TextureWidth = bs.readUInt() TextureHeight = bs.readUInt() TextureBufferSize = bs.readUInt() data = bs.read(TextureBufferSize) if PixelFormat == 5: texFmt = noesis.NOESISTEX_RGB24 print("Pixel Format > RGB") elif PixelFormat == 8: texFmt = noesis.NOESISTEX_DXT1 print("Pixel Format > DXT1") elif PixelFormat == 9: texFmt = noesis.NOESISTEX_DXT3 print("Pixel Format > DXT3") elif PixelFormat == 10: texFmt = noesis.NOESISTEX_DXT5 print("Pixel Format > DXT5") else: print("Unknown Pixel Format > ",PixelFormat) texList.append(NoeTexture(rapi.getInputName(), TextureWidth, TextureHeight, data, texFmt)) return 1

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 have researched this container. Format BLK\PLK. struct Entry { u32 offset; }; struct File { u32 count; Entry entries [count]; u32 allFileSize; }; File a @ 0x0;And simple extractor, possible drag-and-drop file on .py script to extract all data. In PLK contains pvr images, other data in container not researched, save as raw data. extractor.py

You can export all textures using the PCSX2 emulator. Checklist "Dump Texture & Dump Mipmaps" and run the game, and the textures will be exported automatically. OPGA.rar

Hi there! Thanks for stopping! There seems to be an issue with retrieving character files from this mobile game called Cookie Run OvenSmash. It's a mobile Unity game, so I figured that I could use AssetRipper to pull the models out of the apk file. While I was able to grab them and port them as a Unity project, the only files that didn't seem to be readable were the character files only, and it could be because they are most likely encrypted. Is there a way around this or any they possibly encrypted and decrypting is the only possible way to use the files? If not, I might be stuck since Idk how to decrypt anything. I can send more screenshots if needed

But that tool was for Soulcalibur, is there a new version?? 😲

It works! Thanks!!!

Yeahh! thank you!! worked like a charm!

Here are my findings for both gamedata.fat and gamedata: gamedata.fat Contains the file allocation table and is zlib compressed. It contains a list of numeric resource IDs and offsets for the main archive after decompression. gamedata One of the many archive and contains a lot of zlib compressed resource bundles. Every bundle contains one or more Onyx engine objects, which are identified by numeric class hashes instead of file names or extensions. These files belong to Ubisoft's proprietary Onyx Engine. So far I have managed to get all texture objects and converted them to PNG for viewing pleasure. Still figuring out the rest...

If I have some extra time I can look into this. No promises, though.

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

It is difficult to find the corresponding skeleton in the file you provided because you did not restore the file name. The script will read the associated files through files with the same name but different endings. For hash file names, the script is basically unable to match them. The second is that none of the skinning folders you provided is a skinning file. ParticleSystem starts with particles C1 59 41 0D starts with the animation skeleton, which is two completely different things from the skinned skeleton. Okay, now comes the hardest part Since this game has a special mesh and may use compression, you have to find a way to match the index and vertex data in the file header The second is to reverse engineer the skin file to find the correct matrix, the most important thing is the level, which will directly affect how you connect the skeleton

Hello, Thank you for this priceless information. I'll definitely try it tomorrow. It's an exciting development.

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