Search the Community

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.

Eutechnyx used to develop racing games, so yeah... I guess thats's all. Anyways, during 6th (PS2, Xbox era) and 7th (Xbox360, PS3) generation they used their own in house engine. This post is exclusively for that. Now, this developer might not ring any bells for most people. Their games were kinda mid. Their most notable games are Street Racing Syndicate (basically We have NFS Underground at home) and Ride to Hell: Retribution (why does this exists?). Thankfully Ride to Hell uses Unreal 3, so it won't be covered, ever. In case I forgot something, here is table of all their titles, that are covered here in some way: Title PC PS2 XBOX GC PS3 X360 WII Absolute Supercars ✔ Big Mutha Truckers ✔ ✔ ✔ Big Mutha Truckers 2 ✔ ✔ ✔ Ferrari Challange ✔ ✔ ✔ Ferrari: The Race ✔ ✔ Ford Mustang ✔ ✔ Ford vs. Chevy ✔ ✔ Hot Wheels: Beat That! ✔ ✔ ✔ ✔ Hummer Badlands ✔ ✔ NASCAR The Game 2011 ✔ NASCAR Inside Line ✔ NASCAR The Game 2013 ✔ NASCAR '14 and '15 ✔ ✔ Pimp My Ride ✔ ✔ Supercar Challange ✔ Cartoon Network Racing ✔ The Fast and the Furious ✔ Street Racing Syndicate ✔ ✔ ✔ ✔ A brief info about the engine The main resource format is called ArcBank with .arc extension. This bank contains all game assets. In it's own sense, it's similar to Unreal Engine 3 pck/upk packages. Each ArcBank is uniquely cooked for each platform. That means, it's harder to research across versions and platforms. Scripts themselves are in plain text and have .ls extension. They also seem to be referencing ArcBanks themselves. There are also other formats, like sound files and streams and language text. All of these files are mostly packed into cdfiles.dat/cdfiles.ar pairs that serves as a main archive format. This is the section where I introduce Technyx Technyx toolset can extract and convert various formats. As of current version. It can extract every cdfiles.dat/cdfiles.ar pair from all titles in the table above. It can also convert ArcBank models, maps and animations, but from a very few selected titles. As a cherry on top, there is a txt converter for language text. Again for all titles. Technyx can be found at: https://github.com/PredatorCZ/Technyx If anyone wishes to use project issues page to report a bug or a new feature, they certainly can. A small gallery of converted stuff

can someone help me regarding something related to binary i correctly reverse engineer and found vertex buffer for head build a head i also found the face indices section as the format was very easy but the problem is i use model researcher and enter the starting offset for face indices it form the faces but in wrong direction as in the picture provided also the format is very easy so if any one wants to help me out the model is also provided as well Wei_Head.perm.zip