Hi everyone,
I'm working on a preservation/reverse engineering project for Mortal Kombat: Shaolin Monks (2005, Xbox version). I'm trying to extract models/textures from GAMEDATA.WAD, GAMEDATA.WAE/.WAF/.WAG/.WAH/.WAI/.WAJ (multi-volume container extracted from the original Xbox ISO via extract-xiso).
There's existing work on this game, but only for the PS2 version:
- ZenHAX thread (archived, forum is now closed): "Tool/script to unpack/repack unknown format [Mortal Kombat Shaolin Monks ewdf]"
- This ResHax thread on PS2 models: https://reshax.com/topic/700-mortal-kombat-shaolin-monks-ps2-models/
The known PS2 tool (aluigi's mksm_ewdf.bms QuickBMS script) targets a container with "EWDF" magic. However, the Xbox version uses a COMPLETELY DIFFERENT and undocumented container format.
=== Header analysis ===
GAMEDATA.WAD (Xbox NTSC version, 314,380,288 bytes)
Hex dump of first 64 bytes:
00000000 50 57 46 20 00 40 86 90 02 00 00 00 71 1c 00 00 PWF
[email protected]...
00000010 00 00 c0 12 00 08 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 e8 00 00 74 01 00 00 00 f0 00 00 f4 00 00 00 ....t...........
00000030 00 f8 00 00 f4 00 00 00 00 00 01 00 00 00 00 00 ................
Magic: "PWF " (0x50 0x57 0x46 0x20) - NOT "EWDF" like the PS2 version.
Fields identified so far (little-endian u32):
- 0x00: magic "PWF "
- 0x08: 2 (possible format version)
- 0x0c: 0x1c71 = 7281 (possible entry count, but doesn't match actual table size - see below)
- 0x14: 0x800 = 2048 (sector size, consistent with sector-based addressing)
- 0x20+: what looks like an index table, entries appear to be (u32 sector_offset, u32 field) pairs, with sector_offset values incrementing by exactly 0x800 (one sector) per entry for the first ~48 entries, then breaking down / going out of valid file range.
I tried parsing this as a flat index table with the entry_count from 0x0c (7281 entries * 8 bytes), but only the first ~48 entries resolve to valid offsets within the file. The table structure is likely more complex than a simple flat array (maybe hierarchical, or mixed with other data).
=== Content analysis ===
Following the sector pointer from the first table entry (byte offset 0x07400000), I ran an entropy analysis on a 64KB sample:
- Shannon entropy: 7.9007 bits/byte (max 8.0)
- All 256 byte values present
- Most frequent bytes: 0x7F, 0xFD, 0xFE, 0xFF, 0xBF
- Least frequent: 0x00, 0x08, 0x04, 0x10, 0x50
This entropy level + biased (non-flat) distribution suggests it's NOT random/encrypted data, but I haven't been able to confirm what it actually is:
- Tried raw deflate (zlib.decompressobj with -MAX_WBITS) scanning sector-aligned offsets across the whole 300MB file - only found 15 tiny valid deflate streams (64-288 bytes decompressed), clearly not the main asset data.
- Tried interpreting as float32 vertex arrays with various strides (12/16/20/24/28/32/36/40/44/48 bytes) - no stride showed a clear signal (all ~40-47% "sane" floats, no standout).
- Tried DXT1 block interpretation - inconclusive (RGB565 values are always "valid" so this test alone can't confirm/deny).
=== Attached samples ===
I'm attaching 3 sample fragments from the Xbox NTSC GAMEDATA.WAD (314,380,288 bytes total):
1. GAMEDATA_sample_1MB.WAD
First 1MB of the file (offset 0x00000000). Contains the full header
and the index table region (0x20 onwards) discussed above.
2. GAMEDATA_sample_8MB.WAD
First 8MB of the file (offset 0x00000000). Same starting point as
sample 1, just more data in case a larger header/table region is
needed for analysis.
3. GAMEDATA_sample_offset_0x7400000_4MB.WAD
4MB fragment starting at byte offset 0x07400000 (the location
pointed to by the first index table entry). This is the
high-entropy data region described in the entropy analysis above
(Shannon entropy 7.9007 bits/byte).
=== What I'm looking for ===
- Does anyone recognize the "PWF " magic / this container format? It might be specific to this Midway engine version, or shared with other Midway Xbox titles from the same era.
- Any pointers on the byte distribution I'm seeing (0x7F/0xFD/0xFE/0xFF/0xBF dominant) - could this be a known compression scheme (LZSS/LZO variant) or a specific texture/geometry encoding?
This is for a legal, non-commercial preservation project (open source PC port using community recompilation tools) - I'm not distributing any copyrighted assets, just trying to understand the format for my own use with a legitimately owned copy.
Thanks in advance for any insight!
GAMEDATA_samples.zip
