BROKEN RAT MAZE
Here is the latest version, if you wanted to take a look at it! Thank you for the feedback what do you recommend I do ?
It seems that the entire map has been corrupted somehow. The mpq header seems intact, but the hash table and block table are useless. I can't tell if the file data is corrupted as well since you need these tables to access them.
I'll try to explain the technical details, a warcraft 3 map is an MPQ archive (comparable to a .zip file). An MPQ file starts with a header that tells you the location of the file data, the hash table, and the block table. Usually the data is in this order (so header first, then file data, then tables), but it's possible to do it differently (for example protected maps may start with the file data and/or tables and put the header afterwards, this is possible because MPQ archives can be embedded in other files, and then the MPQ header can be found by checking for a 'magic' number). The header itself is fine, it says the file data is at offset 32 (directly after the header), and the tables are at roughly 40000000 (which should be around 38.4MB, the size of the file). The problem is that the hash table and block table are corrupted. The hash table is used to find the entry in the block table given a filename (war3map.w3i, war3mapMap.blp, etc), then the block table tells you where the file is and what its size is. Note that the filenames are not stored in an MPQ archive, only the hashes. What I noticed is that after the first couple of entries in the hash table, every three entries all have the same data. It's all garbage though so I'm not sure it means anything. The block table has 84 entries (files) according to the header. Then there's the files themselves, assuming these didn't get corrupted like the hashtable and blocktable, without the tables all you really know is that the first file starts at offset 32 (directly after the header), and the second file will probably start directly after the first one, but you don't know the size of the first file, that information is stored in the block table.
I don't know if anyone ever attempted to recover files from an MPQ archive, but in theory it may be possible, because the map is not protected we can make some assumptions.
First of all the world editor will save all files in a specific order: war3map.w3e, war3map.w3i, ..., imported files, (listfile), (attributes). The last two are files specific the MPQ archives and will be compressed and encrypted, the others will only be compressed. MPQ compression is usually done in blocks of 4kB. At the start of the data is an offset table, for every 4kB part is an offset, for example a file that is 200 bytes compressed will have an offset table of [8, 208] (the offsets includes the offset table itself, so because there are two offsets the first offset is two multiplied by 4 (the size of one offset). Now we know the compressed size of the file, so we know where it ends and so where the next file starts. Only thing we don't know is the UNcompressed size of the file. I don't know if you really need to know this (might depend in the compression algorithm), but at least we know that every block means 4kB uncompressed size, and the last one's uncompressed size should be larger than its compressed size, but no larger than 4kB (if the compressed and uncompressed sizes are equal (usually if the last block is very small) then the data should be uncompressed, not sure about when compressed is larger than uncompressed).
So if you put this theory to practice what do you get? A bunch of files but without their file names (and file extensions). I said before the MPQ doesn't store the filenames, but that's actually not true, they are stored in the (listfile) that I mentioned earlier (the () is part of the filename). This file will not tell you which file had which filename, but if you check the files you should be able to tell what file type (extension) it should have, for example if it should be a BLP file. Then if you know it's a BLP file you can open it to see the image, and find the correct filename from the list. Same goes for MDX files (models), etc.
Of course all of this only works if the file data has not been corrupted like the hash table and block table. I'll check tomorrow to see if I can retrieve any files from the MPQ.
