Findings Summary – MPK Patch vs Resource Analysis (Where Winds Meet)

[Myro]

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.