All Activity

here are some common structures: fat pointer the red value is a pointer, purple value is element count, brown value tells if its not null array contains a fat pointer, and the pink value is the array length string contains an array, yellow value is string length, and the cyan value is the string hash (xxh64) class the purple value is non-zero if it is inherited from another type. the brown value is always max. asset header the blue value is the payload size, the orange value is the number of 16 byte sized values (idk), the green value is the count of pointers to classesin the payload, and the red value is the count of pointers to pointers in the payload. *buuuuuuuuuuuuuurrrrrrrrrrrrrrrrrrrp* haha

oh i see now! But yes, I'll wait for Dave for now, because I have absolutely no ideas and understanding of how to continue.

Your pictures shows use of signed shorts, imho. (characteristic splitting of the mesh into 4 separated parts) using unsigned shorts # 0x920: verts= 156 v 134.273438 160.218750 119.273438 v 137.363281 160.218750 105.683594 v 145.921875 150.296875 124.898438 v 150.296875 150.296875 105.683594 v 154.863281 137.363281 129.218750 ... signed shorts # 0x920: verts= 156 v -121.726562 -95.781250 119.273438 v -118.636719 -95.781250 105.683594 v -110.078125 -105.703125 124.898438 v -105.703125 -105.703125 105.683594 ... (The actual values depend on the factor (or divisor) used for the conversion.)

Well, that's what I've done since the beginning of the topic... this is odd, I don't have this problem with other model formats.

You'll need to use unsigned shorts for vertices here. That's why I wrote about "terminator" FF. But not sure whether .rpm uses triangle strips. You could skip the bytes bigger than 0x9C for a test. Or you could wait for Dave.

I'm... a little confused rn. How did you make this model so that it looks like... a sphere? To make you understand what I mean, right now my sphere looks like this: ...I really thought that's okay for this rpm models ._. this is what the model looks like with my template from the archive I tried to do this, but it doesn't work for me because there are fewer vertices than the number of bytes that follow this address (total vertices is 0x9C, and here there is 0xFF) If I understood you correctly, then each 0x98 should be followed by the following: faces, then vertices, UVs and normals? I tried to do this, but I only get a cloud of vertices.

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 01 96 01 34 00 31 01 46 20 11 00 00 07 00 00 00 07 20 00 00 0A C8 00 00 0E 34 00 00 00 00 All I can say about the header is that 01 34 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) UPD: I just noticed that I used a header from another model as an example. Now the header is from the archive 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":