All Activity

You can do it like this: 1. Open GFX file in hex editor (e.g. Hex Workshop) 2. Delete first 256 bytes 3. Save file 4. Change file extension to GXT 5. Convert GXT file with Scarlet https://github.com/xdanieldzd/Scarlet ScarletTestApp.exe "gravite (2).gxt" 6. You'll get PNG file as a result P.S. Some files are not supported by Scarlet, so you can use ImageHeat for manual conversion https://github.com/bartlomiejduda/ImageHeat

I am trying to rip the images from Hayarigami 1.2.3 on switch and it uses a .dat file format here is a file from Hayarigami 3 from the 1.2.3 Collection https://drive.google.com/file/d/1zdSfck87_f5XrwQpK0tP8FJ6kLh6re-x/view?usp=sharing

It seems as though the model data starts at 0x200 with a 0x20-byte header, which contains some offsets to the data sections relative to 0x200. So you've got 0x720 for vertices, 0xac8 for UVs, 0xe34 for normals maybe. The 0x31 in this header indicates the number of face sections (0x31 = 49) starting just after this header. Each face section starts with a face type - 0x98 seems to be a tri-strip, then a short count value, followed by 4 bytes per count. These 4 bytes are probably texture number (not sure), then it's something like vertex number, UV number, normal number. So you have to reconstruct the buffers because they're not a direct 1:1 match. For example, you have more UVs than vertices.

Hello! You could try using byte face indices starting from 0x1034 in the .rpm. (I thought of using strips with 0xFF being the terminator but the sequence FF 7F FF at 0x1088 seems to exclude that.) Auto generated faces are too ugly:

Why not? (unsure about uvs)

Hello! I tried to rip models from Spore Hero, and I was able to handle the vertices and UV coordinates, but I had problems with faces: I can't find their exact data at all. All I know about the rpm structure at the moment is that polygons have a "blocked" structure: a polygon that consists of faces(?), vertices, UV coordinates, and possibly some other information. Each such polygon has the following header: 50 48 00 3E 00 20 00 0F 01 46 20 11 00 00 01 40 00 00 01 60 00 00 01 CC 00 00 02 74 00 00 00 00 All I can say about the header is that 00 20 indicates the number of faces. How can I understand this if I can't display them? Well, the game Spore has exactly the same models in a different format (.rw4/.rdx9), but not all of them. Immediately after the header, there are presumably faces, and here repeats the bytes 98 00 04 00, after "faces" following 16 bytes of 00, then vertices and UV cords. Here is an archive with the model and the addresses of the vertices and UV cords: (Hope this info helps to figure out how rip rpm models) CE_simple_sphere.zip

A new thread focused on technical exploration of this game has been opened. Feel free to check it out and leave any comments or insights.

Author: Myro Scope: Educational & research-oriented reverse engineering Status: Ongoing research Introduction: This thread documents an ongoing technical research project focused on analyzing the MPK container system used by Where Winds Meet (WWM). The goal is to understand the structure, behavior, and data flow of the game’s asset containers from a reverse-engineering and archival perspective, strictly for educational and analytical purposes. No proprietary assets, binaries, or tools will be distributed as part of this work. 1. Patch*#.mpk vs Resource*#.mpk — Structural Similarity, Semantic Differences At a container level, Patch#.mpk* and Resource#.mpk* share the same base format: Indexed via mpkinfo / mpkdb Entries contain: FileID Size Offset MpkIndex Use the same compression stack: LZ4 / ZSTD / LZMA EZST (AES-encrypted) However, despite this structural similarity, their extraction semantics differ significantly. 2. Patch*#.mpk — Partial Transparency, Direct Asset Access Patch MPKs behave primarily as delta / override containers: Assets retain near-original offsets Internal file structures remain largely recognizable Minimal indirection compared to Resource MPKs As a result: ~99% of audio assets can be recovered successfully A subset of Lua scripts becomes readable after decompression Non-audio assets (including some images) are present and partially accessible Testing on Patch3100.mpk confirmed that Patch archives are not limited to sound assets. Conclusion: Patch MPKs prioritize update efficiency and fast access, with limited transformation of payload data. 3. Resource*#.mpk — Indirection and Shared Data Resource MPKs represent the primary asset pool and introduce several additional complexities: The Size field often represents a logical or expanded size, not the physically stored payload Naïve extraction pipelines tend to: materialize padding and alignment blocks duplicate shared data blobs inflate archive size artificially (e.g. ~2 GB → tens of GB) This behavior explains why Resource MPKs appear far more “opaque” when extracted without validation. Important observations: Fixed headers such as 02 02 02 01 … frequently represent logical structures (e.g. texture containers with multiple mip blocks) Headers of the form size (4 bytes) + size × 20 bytes often describe lookup tables, not standalone assets Many assets are shared, aliased, or referenced indirectly Conclusion: While Patch and Resource MPKs share the same container format, they do not share the same extraction semantics. Resource MPKs require strict validation, deduplication, and asset-type verification to avoid false positives. 4. Audio Extraction & Tooling Initial testing with Ravioli Game Tools proved sub-optimal for this pipeline: Inconsistent parsing of Patch audio assets Unreliable WAV output in multiple cases Switching to vgmstream yielded significantly better results: Correct parsing of recovered audio data Clean, fully functional WAV output Proper handling of codec structures Current result: Audio extraction and conversion are fully verified and stable. 5. Resource.mpk Extraction – Current Progress Testing on Resources49.mpk (~740.9 MB) produced the following results: Successfully extracted: Audio assets → converted to valid .wav files Over 8,500 audio files identified in a single Resource MPK Video files (.mp4) → fully playable Lua scripts (.lua) → extracted but still encrypted / obfuscated Unresolved: Files detected as images (.png, .jpg, .bmp) Headers contain the string “messiah” Strongly suggests custom packing, encryption, or misclassification Currently not valid image data despite file extensions 6. Current Status ✔️All Patch*#.mpk, Resource*#.mpk, and lt*.mpk archives can be unpacked ✔ Audio assets fully recovered and validated ✔ MP4 video assets fully playable ✔ Lua scripts extracted but not yet readable 7. Next Steps Ongoing research will focus on: Reversing additional transformation layers in Resource*#.mpk Identifying: secondary encryption stages compression chaining block or stream reordering Investigating the custom image container format Further analysis of Lua encryption / obfuscation Automating Patch vs Resource handling as two distinct pipelines Notes on Tooling & Distribution All tools used in this project are: developed entirely from scratch created specifically for WWM research used strictly for educational purposes At this stage: no tools, binaries, or scripts will be released no proprietary assets will be redistributed Closing This thread is intended solely as a technical research and documentation log, not as a release, redistribution, or exploitation guide. In accordance with applicable intellectual property laws and forum policies, no tools, binaries, scripts, or extracted assets will be posted or shared, either publicly or privately. All game data, assets, file formats, and related materials discussed here remain the exclusive proprietary property of NetEase and the developers of Where Winds Meet. Any references to assets or file structures are made strictly for educational, analytical, and research purposes, with no intent to enable misuse, circumvention, or redistribution of protected content. Should any concerns arise regarding compliance or scope, I am fully open to cooperating with forum moderation and adjusting the visibility or content of this thread accordingly. Thank you for your understanding and for supporting responsible technical research. — Myro Below are a few illustrative screenshots and log excerpts from the current stage of the research, provided solely to contextualize the findings outlined above.

Progress update on MPK extraction I’ve managed to successfully extract Resources.mpk (tested specifically on Resources49.mpk, ~740.9 MB). From this archive, I was able to extract and convert all audio assets to .wav format. The resulting files are fully functional and have been tested. Interestingly, this single MPK contains over 8,500 audio files, which is far more than expected. In addition to audio, I extracted: Multiple video files (.mp4) — all verified and fully playable A large number of Lua scripts (.lua) Several files detected as images (.png, .jpg, .bmp) However, the extracted image files do not appear to be valid images. Their headers contain the string “messiah”, suggesting they are either encrypted, packed in a custom format, or falsely identified by the extraction tool. Despite this, the tool currently classifies them as standard image formats. At this stage, I can: Fully unpack patches.mpk, resources.mpk, and lt*.mpk Extract and convert all audio assets into working .wav files Extract all Lua scripts (still encrypted/obfuscated, with many unknown WWM-specific variables) Extract and play all embedded .mp4 files without issues Next steps will likely involve: Investigating the image file format to determine why they are corrupted or misidentified Attempting proper decoding or conversion of those image assets Further reverse engineering to fully deobfuscate and restore the Lua scripts into a readable form Any insights regarding the image headers or Lua decryption would be greatly appreciated. I’m considering opening a dedicated thread on this forum for this project, but I haven’t decided yet. If there’s interest in seeing further progress, feel free to leave a like or a comment, and I’ll take it from there.

At this stage, it is not available. The project has been developed strictly for training and research purposes, and I am not planning to share either the tool itself or the technical details regarding its construction for the time being. A complete public release may be considered in the future, once I have fully analyzed and successfully decrypted all core components of the game, including the MPK resources and the Lua scripts in their entirety. Maybe @wq223woudlbe able to share some infos about that if he/she is still trying to decript the lua?

Does anyone know how to convert this to PNG? Texgfx.zip

I extracted these files from my legitimate copy of Gravity Rush. I was wondering if there was a way to put these files into Blender. 3Dgfx.zip

somebody tried to reverse engineer those files but fail in AnimeStudio's Issues (a fork of AssetStudio that supports encryption on some games) https://github.com/Escartem/AnimeStudio/issues/32 (i know you're on there)

https://github.com/bartlomiejduda/ImageHeat/releases/tag/nightly

It not something that i can or should share

Is there somebody I should contact to get this added to Image heat? Thank you so much for your help

This looks correct. The palette is RGB5551, but is swizzled with the same method as the image (not the standard PS2 palette shift). Patrick should be able to confirm if that can be added to ImageHeat as a palette swizzle option.

uses Mummggtool swizzzle 8 bit as per mentioned yt Dk Dave, can´t find pallet.

You'd be better using ImageHeat, as it has more options for swizzling, etc. For these, the image is PS2 swizzled, but I can't work out the palette. It doesn't seem to use any of the standard PS2 palette formats, maybe a different swizzling method. This is from "t_compact_rockangelz_closed_00000003":

Hi, I have been trying for sometime now to convert the texture files of Bratz Rock Angelz for the playstation 2 made by Blitz games. I have been using "TiledGGD" as I saw a previous post (for a Spongebob game made by the same Developers) recomend it for files of a similar era. This is as far as I have gotten. I have attached various files from the game, please could you point me in the right direction or let me know how to decipher them. Thank you so much for your help. ps2TexSamplesBratz.zip

Ninja ripper works but not always, the best way is to extract models from game files. Now, each of those KMDs blocks have a skeleton(I don't know why you need so many, that is weird), I cut the first KMDs at 0x190 and this is part of the header(see image below). Now we need to analyze mesh headers of KMDs and KMDp. It seems like KMDp header is more easy to undersntand. I will try to analize both later.

The game has a debug mode, maybe this will help in some way.

I wanted some way to modify it, but it's okay if there isn't an easy way to do it From what I see in the PS2 model, it's separated into parts, and when ripped directly from the game using Ninja Ripper, it's possible to erase some details, revealing, for example, the arms (covered by a type of armor) and the neck by removing the scarf. If its too complicated to edit the model or do anything, that's fine, im hoping to at least have a better way to extract them without using Ninja Ripper. It still would help alot.

Wait, I think I did something wrong, lol. I can see other unknow block or buffer before UVs. I thought that was the start of UVs but no! So Uvs have the same count as verts after all. The format is: verts/normals buffer: 3 shorts verts, 1 short flag, 3 shorts normals, 1 short flag. unk buffer: ?? UVs buffer: 2 shorts UVs, 4 bytes unk(maybe vertex colors?) Well, it looks like that but I am not sure. About the meshes with floats is: verts/normals buffer: 3 floats verts, 1 short flag, 1 short pad, 3 floats normals, 1 short flag, 1 short pad UVs buffer: 2 shorts UVs, 4 bytes unk(maybe vertex colors?) So meshes with floats don't have that unk buffer. And like always, each buffer has a 4 bytes tag, Here is the last part of the 1st submesh, you cn see that unk buffer before UVs:

Adding this small reply to myself to state... I normally would not do this when asked to take a look at something like these animations.... but because I thought it would be very easy.... I became a bit obsessed with trying to figure it out. I only had Xbox and PS2 copies of the games using this format to work with but mainly focused on Xbox only. Sorry about that. The names of the sample files in the uploads above were for testing purposes and an animation that was sent to me by the one that asked me to look into the animations. The samples were for testing purposes so you can ignore those unless you really want to mess with them.