Has anyone know how to get audio resources in netease new game where winds meet?

[reopio]

This game is developed with newer messiah engine. I dumped into the resource files which are .mpk files. However, it seems that these files are using version 3 which are no compatible with previous ways. Also, mpkinfo files are deprecated for some data. Anyone knows how to handle these files?

[wq223]

2025年2月4日上午3点32分，reopio 说：

这游戏采用较新的messiah引擎开发。我将其转储到资源文件中，即.mpk文件。但是，这些文件似乎使用的是版本3，与以前的方式不兼容。另外，mpkinfo文件对于某些数据已废弃用。有人知道如何处理这些文件吗？

Hello, you can try the script I wrote. It will parse the Where Winds Meet patch file. I have uploaded the script to the script section. It should be easy to parse the audio file to

mpk.py

[reopio]

On 2/7/2025 at 1:21 PM, wq223 said:

Hello, you can try the script I wrote. It will parse the Where Winds Meet patch file. I have uploaded the script to the script section. It should be easy to parse the audio file to

mpk.py 7.72 kB · 2 downloads

Thanks for your reply. I tried your script and it extracted a lot of files. I find all audio files which are all .wav files via another script by magic code. However, the extracted .wav files cannot played by VLC player and cannot be recognized by ffmpeg which tells they are using a kind of unknown codec. Here is a example header of these extracted .wav files: 

52 49 46 46 BF 73 00 00 57 41 56 45 66 6D 74 20 24 00 00 00 41 30 01 00 80 BB 00 00 F5 12 00 00 
00 00 00 00 

from which we can see that the code 41 30 01 00 which means the codec of this .wav file is not standard. So we cannot play it in VLC. Do you know how to convert them into standard .wav files or is there a player can play these .wav files?

[wq223]

Hello, although the file is recognized as .wav format by the system, it is actually a .wem format commonly used by the Messiah Engine. Of course, the .bnk format may also appear. You can use this tool to download a version suitable for your system. You can use the command Lines convert it to standard .wav audio or other audio formats

https://github.com/vgmstream/vgmstream

 

Of course you can also use the following exe program. I have used it before and can be converted in batches. Before using it, you should modify the file name to .wem. If the file header is BKHD, you should also modify and expand to .bnk

RavioliGameTools_v2.10.zip

[wq223]

On 2/12/2025 at 7:20 PM, reopio said:

Thanks for your reply. I tried your script and it extracted a lot of files. I find all audio files which are all .wav files via another script by magic code. However, the extracted .wav files cannot played by VLC player and cannot be recognized by ffmpeg which tells they are using a kind of unknown codec. Here is a example header of these extracted .wav files: 

52 49 46 46 BF 73 00 00 57 41 56 45 66 6D 74 20 24 00 00 00 41 30 01 00 80 BB 00 00 F5 12 00 00 
00 00 00 00 

from which we can see that the code 41 30 01 00 which means the codec of this .wav file is not standard. So we cannot play it in VLC. Do you know how to convert them into standard .wav files or is there a player can play these .wav files?

Hello, is there a problem with the method provided, can the audio be extracted correctly?, If there is no problem, please mark the previous message as a solution to let others know that your problem has been resolved

[reopio]

On 2/12/2025 at 10:46 PM, wq223 said:

Hello, although the file is recognized as .wav format by the system, it is actually a .wem format commonly used by the Messiah Engine. Of course, the .bnk format may also appear. You can use this tool to download a version suitable for your system. You can use the command Lines convert it to standard .wav audio or other audio formats

https://github.com/vgmstream/vgmstream

 

Of course you can also use the following exe program. I have used it before and can be converted in batches. Before using it, you should modify the file name to .wem. If the file header is BKHD, you should also modify and expand to .bnk

RavioliGameTools_v2.10.zip 5.02 MB · 1 download

Thanks a lot, you saved my life. Another question. I also want to get In game dialogue text from extracted data. I use file command to detect file type and find that all files marked as text/plain has no data at all. They are consist of the following looped hex data:

Do you know how to find In game dialogue text data? Thank you for your help.

[wq223]

18 hours ago, reopio said:

非常感谢，你救了我的命。另一个问题。我也想从提取的数据中获取游戏内对话文本。我使用文件命令检测文件类型，发现所有标记为文本/纯文本的文件都没有数据。它们由以下循环十六进制数据组成：

你知道如何查找游戏内对话文本数据吗？谢谢你的帮助。

In other Messiah engine games, text files are embedded in scripts, but in the game we are discussing, I did not find any traces of script files. Maybe they modified the compression and encryption methods, causing changes in the file surface. What I doubt most at the moment is EZST encrypted files

In other Messiah engine games, text files are embedded into scripts, they use zlib to compress and exorbit it or

If zlib compression is used, the fixed byte part must be two digits

But the fixed byte EZST here is obviously four bits. Assuming that it stores the script, it will not be zlib compression, because the fixed byte part has exceeded the limit.

Or fixed bytes are exceptions, they are not compressed file data

All are based on guesswork

In addition, regarding their texture files and mesh model files, the encrypted lz4 algorithm is used. Someone has written their decryption script before, but I can't tell if it works.

[reopio]

On 2/15/2025 at 3:40 PM, wq223 said:

In other Messiah engine games, text files are embedded in scripts, but in the game we are discussing, I did not find any traces of script files. Maybe they modified the compression and encryption methods, causing changes in the file surface. What I doubt most at the moment is EZST encrypted files

In other Messiah engine games, text files are embedded into scripts, they use zlib to compress and exorbit it or

If zlib compression is used, the fixed byte part must be two digits

But the fixed byte EZST here is obviously four bits. Assuming that it stores the script, it will not be zlib compression, because the fixed byte part has exceeded the limit.

Or fixed bytes are exceptions, they are not compressed file data

All are based on guesswork

In addition, regarding their texture files and mesh model files, the encrypted lz4 algorithm is used. Someone has written their decryption script before, but I can't tell if it works.

Thank you very much. I will try x64dbg to find anything useful if possible or just use TTS to get scripts.

[wq223]

4 hours ago, reopio said:

非常感谢。如果可能的话，我会尝试使用 x64dbg 来查找任何有用的东西，或者只是使用 TTS 来获取脚本。

If you are a big guy, you can try reverse their binary, maybe (libgame.so) or something, to find the relevant logic of compression, how they encrypt, how they compress, and if you are lucky, it may also be the way to go Find other useful information

But it is best not to try to find something on a single compressed file. The file may have been compressed, XOR, reversed, and encrypted, making the file no longer what it was.

I'll share a way to reverse the script compression method of other messiah games before

In other messiah games (probably part) there are several pyc files embedded at the end of the so file

But this kind of pyc cannot be decompiled, but I can get the key through disassembly

Just a simple XOR, by converting the header of the original file with the obtained key, I got the file header of zlib

But the file cannot be decompressed. I tried to perform 2 bytes of XOR operation at a time, and then tried to decompress, and then learned that XOR has no XOR all bytes

So I understand the basic logic of compressing script files

Unzip it into a .pyc file, and the text information is included in it

But this method should not apply to Yanyun Sixteen Sounds, because I have not seen the original file with the same bytes in Yanyun Sixteen Sounds.

[Unlock777]

I would like to translate the dialogue text into my language. Would anyone be kind enough to help me decrypt only that file (and vice versa)?

[windsa]

+1 for this . anyone know a tool to unpack wwm resource. I want get extract text  and audio.

[trunganhfa99]

On 19/2/2025 at 19:32, wq223 said:

Nếu bạn là một người lớn, bạn có thể thử đảo ngược nhị phân của họ, có thể là (libgame.so) hoặc thứ gì đó tương tự, để tìm logic nén có liên quan, cách họ mã hóa, cách họ nén và nếu bạn may mắn, đó cũng có thể là cách để thực hiện. Tìm thông tin hữu ích khác

Nhưng tốt nhất là không nên cố gắng tìm kiếm thông tin trong một tệp nén duy nhất. Tệp có thể đã được nén, XOR, đảo ngược và mã hóa, khiến tệp không còn nguyên vẹn như ban đầu.

Tôi sẽ chia sẻ một cách để đảo ngược phương pháp nén tập lệnh của các trò chơi messiah khác trước

Trong các trò chơi messiah khác (có thể là một phần) có một số tệp pyc được nhúng vào cuối tệp so

Nhưng loại pyc này không thể dịch ngược được, nhưng tôi có thể lấy được khóa thông qua việc tháo rời

Chỉ cần một phép XOR đơn giản, bằng cách chuyển đổi tiêu đề của tệp gốc bằng khóa thu được, tôi đã có được tiêu đề tệp của zlib

Nhưng tệp không thể giải nén được. Tôi đã thử thực hiện 2 byte phép toán XOR cùng một lúc, sau đó thử giải nén, và sau đó phát hiện ra rằng XOR không có XOR tất cả các byte.

Vì vậy, tôi hiểu logic cơ bản của việc nén các tệp tập lệnh

Giải nén nó vào một tệp .pyc và thông tin văn bản sẽ được bao gồm trong đó

Nhưng phương pháp này không áp dụng cho Yanyun Sixteen Sounds, vì tôi chưa thấy tệp gốc có cùng số byte trong Yanyun Sixteen Sounds.

 

bro, how to replace default font of wwm game

[Myro]

Findings Summary – MPK Patch vs Resource Analysis

After an in-depth analysis of the MPK archives, I have identified clear structural and functional differences between Patch*#.mpk files and Resource*#.mpk files. The results so far are outlined below.

------------------------------------------------------------------------------------------------

 

1. Patch*#.mpk – Partial Transparency, Direct Asset Access

 

• Patch*#.mpk archives use a different internal layout compared to Resource*#.mpk.
• Although Patch archives are compressed and encrypted using the EZST mechanism, the embedded files:

1. retain near-original offsets
2. preserve recognizable internal structure

 

• As a result:

1. ~99% of audio assets can be recovered successfully
2. a subset of Lua scripts is readable after decompression

 

• Additionally:

1. I was able to extract several image assets from the latest Patch3100.mpk, confirming that non-audio assets are also present and partially accessible in Patch archives.

Conclusion:
Patch*#.mpk files act more like delta/update containers, prioritizing fast access and minimal transformation of asset payloads.

 

------------------------------------------------------------------------------------------------

2. Resource*#.mpk – Multi-Layer Obfuscation

 

• Resource*#.mpk files are also:

1. compressed and encrypted using EZST

 

• However, unlike Patch archives:

1. extracted payloads appear to be re-encrypted, recompressed, or further transformed
2. file contents are likely:

• wrapped in an additional encryption layer
• compressed again
• or stored in a reversed / custom-serialized layout

 

• Due to this:

1. no successful decryption or reconstruction of Resource assets has been achieved so far
2. standard tools and known compression signatures do not match

Conclusion:
Resource*#.mpk archives are designed as primary asset containers, with significantly stronger obfuscation to prevent direct extraction.

 

3. Audio Extraction & Conversion Tooling

 

• Ravioli Game Tools proved to be sub-optimal for this specific pipeline:

1. inconsistent parsing of Patch audio assets
2. unreliable WAV output in several cases

• Instead, I switched to vgmstream, which:

1. correctly parses the recovered audio data
2. produces clean, fully functional WAV files
3. handles the recovered codec structures more reliably

4. Current Status & Achievements

 

• ✔ Successfully decompressed and decrypted all Patch*#.mpk archives
• ✔ Recovered and converted:

1. audio files → valid .wav
2. selected Lua scripts
3. selected image assets

• ✔ Audio conversion verified and validated

Below is a proof-of-concept output, demonstrating a successfully recovered and converted audio file:

• 🔊 Converted WAV audio (proof):

1. Google Drive Download WAV File

 

5. Next Steps (Ongoing Research)

 

• Reverse additional transformation layers in Resource*#.mpk
• Identify:

1. secondary encryption keys
2. compression chaining
3. possible stream or block reordering

• Automate Patch vs Resource handling as two distinct pipelines

 

Edited 12 hours ago by Myro
add images

[kurator]

Resource*.mpk and Patch*.mpk have the same structure. Resource*.mpk are the original files, Patch*.mpk are the modified files. A file from Patch*.mpk with the same FileID replaces a file from Resource*.mpk.
Information about files (FileID, Size, Offset, MpkIndex) is stored in mpkinfo/mpkdb.
The files are compressed in various formats. EZST is additionally encrypted.
Some files have a fixed header of 56 bytes (0x02, 0x02, 0x02, 0x01, ...), followed by the body the file.
Some files have a header "size (4 bytes) + size x 20 bytes".

[Myro]

3 hours ago, kurator said:

Resource*.mpk and Patch*.mpk have the same structure. Resource*.mpk are the original files, Patch*.mpk are the modified files. A file from Patch*.mpk with the same FileID replaces a file from Resource*.mpk.
Information about files (FileID, Size, Offset, MpkIndex) is stored in mpkinfo/mpkdb.
The files are compressed in various formats. EZST is additionally encrypted.
Some files have a fixed header of 56 bytes (0x02, 0x02, 0x02, 0x01, ...), followed by the body the file.
Some files have a header "size (4 bytes) + size x 20 bytes".

You are broadly correct, but there are a few important nuances worth clarifying based on deeper analysis of the container behavior.

 

• Structure-wise, Resource*.mpk and Patch*.mpk indeed follow the same container format, and both are indexed through mpkinfo / mpkdb entries containing FileID, Size, Offset, and MpkIndex.
• Semantically, however, they behave very differently:

1. Resource*.mpk act as the base asset pool.
2. Patch*.mpk act as overrides, where a matching FileID replaces the corresponding entry from Resource*.mpk.

• While both containers use the same compression stack (LZ4 / ZSTD / LZMA, with EZST being AES-encrypted), Patch MPKs are generally much closer to “flat assets”, whereas Resource MPKs contain a significant amount of indirection and shared data.
• The presence of:

1. a fixed 56-byte header (02 02 02 01 …)
2. or the size + size × 20 bytes header

is correct, but these headers often represent logical structures or lookup tables, not necessarily standalone files.

• A critical detail is that in Resource*.mpk, the Size field frequently represents a logical or expanded size, not the physically stored payload size. Treating it as a raw read length will materialize padding, alignment, and shared blobs that are not real assets.
• This explains why naïve extraction pipelines can easily inflate a ~2 GB Resource*.mpk set into tens of gigabytes:
  the extractor ends up writing engine metadata, alias entries, and shared blocks as if they were unique files.

In short:

• ✔ same container format
• ✔ same compression/encryption stack
• ❌ not the same extraction semantics

Patch MPKs are mostly straightforward; Resource MPKs require additional validation (deduplication, strict decompression checks, and asset-type verification) to avoid false positives and artificial size inflation.