Watchmen The End is Nigh .naz, .block_h_z and .block_s_z

[burom]

I'm trying to extract as much as I can from Watchmen The End is Nigh Part 2, I can get models and textures indirectly through playing the game and using Ninja Ripper but the audio is elusive, so I'm now looking at the game data to try to get an idea.

The game data comes in about a 1GB game.naz file, it's by the same developers as Total Overdose so that game's naztozip tool (viewtopic.php?t=9500) seemingly works to extract it into a few large files for each level, .block_h_z and .block_s_z. Opening the block_s_z in a hex editor shows mostly gibberish while the block_h_z shows some plaintext filenames ("/sounds/Effects/DoorAndGates/switch_down_02.wav", "/art/props/common/grafitti/textures/Grafitti_Bizarre_05.bmp", etc) followed by gibberish. Running offzip on the files spits out a bunch of .dat files, some of which seem to be extremely garbled audio files when loaded as raw audio into Audacity.

A long time ago I tried doing this and ended up decompressing the block_h_z and block_s_z files somehow, unfortunately I didn't note down the steps but I still have the decompressed files. Loading the decompressed block_s_z into Texture Finder, setting to DXT5 and fiddling with the shift value does produce textures that match with what Ninja Ripper pops out: https://imgur.com/a/5h0QkaS

Here are sample files, one each of block_h_z and block_s_z files, their respective decompressed versions (bhz.dat and bsz.dat), plus one of the garbled audio dat files from offzip (importing as 8-bit unsigned PCM mono 44100 Hz and playing back at half speed seems to be the least garbled method): https://mega.nz/folder/OAMQmZ6K#etcZx0itC8Cr329hI2rdtA

[grandshot]

Test script

Code: Select all

# Watchmen The End is Nigh test script for QuickBMS
# Kapow Systems 3D Engine *.block_h_z; *.block_s_z
# Both files must be in same folder

open FDDE "block_h_z" 0 #binary headers
open FDDE "block_s_z" 1 #data streams

goto 327 0

get UNKNOWN byte 0
get UNKNOWN long 0
get TABLES_SIZE long 0
get UNKNOWN long 0
get UNKNOWN long 0
get UNKNOWN long 0
get UNKNOWN long 0
get NUM_TABLES long 0
get UNKNOWN long 0
get UNKNOWN long 0

goto 399 0
savepos TABLES_OFFSET 0
xmath DATA_OFFSET "TABLES_OFFSET + TABLES_SIZE + 1"

for i = 0 < NUM_TABLES
   goto TABLES_OFFSET 0
   get FLAG byte 0
   if FLAG > 0
      get S_BLOCK_OFFSET long 0
      get S_BLOCK_SIZE long 0
      get S_BLOCK_OFFSET long 0
      get S_BLOCK_SIZE long 0
      get S_BLOCK_OFFSET long 0
      get S_BLOCK_SIZE long 0
      get S_BLOCK_OFFSET long 0
      get S_BLOCK_SIZE long 0
      get S_BLOCK_OFFSET long 0
      get S_BLOCK_SIZE long 0
      get S_BLOCK_OFFSET long 0
      get S_BLOCK_SIZE long 0
   endif
   
   get SIZE long 0
   get SIZE long 0
   get SIZE long 0
   get SIZE long 0
   get SIZE long 0
   get SIZE long 0
   
   get UNKNOWN long 0
   get NAME_LENGTH long 0
   getdstring FILE_NAME NAME_LENGTH 0
   
   #print "%i% %DATA_OFFSET% %SIZE%\n"
   
   savepos TABLES_OFFSET 0
   
   if FLAG > 0
   
      string FILE_NAME_S = FILE_NAME
      string FILE_NAME_S + ".stream"
      
      goto S_BLOCK_OFFSET 1
      get TEST_BYTE byte 1
      
      if TEST_BYTE == 0x78
         clog FILE_NAME_S S_BLOCK_OFFSET S_BLOCK_SIZE 64000000 1
      else
         log FILE_NAME_S S_BLOCK_OFFSET S_BLOCK_SIZE 1
      endif
      
      string FILE_NAME + ".header"
   endif
   
   goto DATA_OFFSET 0
   get TEST_BYTE byte 0
   
   if TEST_BYTE == 0x78
      clog FILE_NAME DATA_OFFSET SIZE 64000000 0
   else
      log FILE_NAME DATA_OFFSET SIZE 0
   endif
   
   math DATA_OFFSET + SIZE   
next i

*.block_h_z file contain file info tables, some small files like anims, and file headers for files from *.block_s_z. Firsts extracts with custom ".header" extension, second with ".stream", for clarity. Files with known extensions like WAV or BMP in real represents proprietary formats and need more reserch.

[burom]

Thank you so much for the script, now to get to decoding the audio ".wav" files...

[burom]

It turns out the console ports (Xbox 360, PS3) use the same filesystem, just in big-endian mode; it looks like the script above works for those provided there's an "endian big" at the beginning.

[aluigi]

Or alternatively putting a "endian guess TABLES_SIZE" after "get TABLES_SIZE long 0".

"endian guess" can't be used with the previous UNKNOWN fields because the first one is 8bit and the other is a timestamp, TABLES_SIZE instead is ideal.

[burom]

Good call, extraction works successfully with that added endian guess line, thank you.