.wz archive

[singga]

Who can help me to make Chinese MS mapdump because they had a new exclusive map.......
I want to know that is there any new monster(not release)in CMS data.wz

[Omega]

I was looking through my data.wz, and the unknown 16 bit number is 0x0060, whcih is diff from what lambda got.

i was looking at the directory structure and it seems fairly simple.
First read the root directory, if it has x folders, then the next x nodes are its sub folders. This function is just an example, it won't work with any of the code already here.

Code: Select all

def readDirs(self):
    numDirs = 0
    print "Node:", self.nodeNum
    self.nodeNum += 1
    temp = self.readNode()
    for ctr in range(temp):
        self.readDirs()

Also, later on there are the files in node 42, Bgm00.img to Bgm13.img, BgmEvent.img, BgmJp.img, BgmUI.img are all uncompressed mp3s. i'm guessing .img is a container format, not an image format. So are there individual file names or just block names?

[Lok]

Meds, where can you get NConvert? I tried searching it, and I downloaded it from this one site, but when I tried to install it, I got an error.

'Access violation at address 004091A2. Write of address 00401000'

Any help?

Edit : It's worked now for some reason. o_o

[Lambda]

I was looking through my data.wz, and the unknown 16 bit number is 0x0060, whcih is diff from what lambda got.

i was looking at the directory structure and it seems fairly simple.
First read the root directory, if it has x folders, then the next x nodes are its sub folders.

Also, later on there are the files in node 42, Bgm00.img to Bgm13.img, BgmEvent.img, BgmJp.img, BgmUI.img are all uncompressed mp3s. i'm guessing .img is a container format, not an image format. So are there individual file names or just block names?

Good observation on the sub folders. The files are also in the same order as they are listed in the file table. I'll do some testing with the subfolder idea. I was worried about assuming things like that, on the chance that it's just a coincidence that the files/directories are in order, or if that's actually the design of the format. I still think that one of the two unknown fields in each file entry is an encoded file offset to the actual entry. My other guesses are a crc32 checksum and the unpacked size of the structures. (unknown 1 ~= 20 * size).

The .img files are container files / structures. See the output from the dump.py script for an example.

[Omega]

I was looking through my data.wz, and the unknown 16 bit number is 0x0060, whcih is diff from what lambda got.

i was looking at the directory structure and it seems fairly simple.
First read the root directory, if it has x folders, then the next x nodes are its sub folders.

Also, later on there are the files in node 42, Bgm00.img to Bgm13.img, BgmEvent.img, BgmJp.img, BgmUI.img are all uncompressed mp3s. i'm guessing .img is a container format, not an image format. So are there individual file names or just block names?

Good observation on the sub folders. The files are also in the same order as they are listed in the file table. I'll do some testing with the subfolder idea. I was worried about assuming things like that, on the chance that it's just a coincidence that the files/directories are in order, or if that's actually the design of the format. I still think that one of the two unknown fields in each file entry is an encoded file offset to the actual entry. My other guesses are a crc32 checksum and the unpacked size of the structures. (unknown 1 ~= 20 * size).

The .img files are container files / structures. See the output from the dump.py script for an example.

Just to note, this is my first time trying to break up one of these files. I'm dumbfounded by how much you figured out so fast and just trying to learn what I can. Anywayz.
About the crc that was my guess as well but i haven't tried (perhaps of the .img). If i were to program a file system i'd probably have the offsets at the beginning, though just adding up the filesizes seems to accomplish the same thing (tested for first 10 or so).
If you are correct about encrypted file positions, it shouldn't be too hard to figure out given that we already know the answer.
The folders do seem to be in order, the last three seem to fit the pattern: last is UI, 2nd last is strings (EULA.img, tooltiphelp), and 3rd last is sound (bgmXX). I haven't bothered to check through the files themselves, my laptop starts to cook if i run it too long (probably due to the amount of info i output, i need to clean that up).

I'm curious where you got the number 5991 from (im assuming number of blocks?) cause i counted the number of files at the beginning and there are only 5959. 44 directories and 47 shortcuts doesn't seem to make up the diff (which is 32, no clue if thats relevant).

I'm sure you know this stuff, but I'll say it anyway. Your immedValue is just a special case of dumpBlock (with obvious benefits) as is your dumpEntryBlock (except for 0x08 which is weird). For dumpEntryBlock, do you think its just they didn't feel like making different codes, or that they're somehow the same function?
Well thats all for me for now.

[Lambda]

Just to note, this is my first time trying to break up one of these files. I'm dumbfounded by how much you figured out so fast and just trying to learn what I can. Anywayz.

I've was working on it off and on for a few weeks privately before the flurry of activity started. That said, I started making some amazing progress after I figured out the text encryption. The zlib hints I read here helped as well. I should have read Mr. Mouse's Guide to Reverse Engineering file formats. It would have explained all that!

You've done good with the time you've spent on it, and you have a talent for noticing patterns, which is huge when trying to figure this type of thing out. You should be proud.

I'm curious where you got the number 5991 from (im assuming number of blocks?) cause i counted the number of files at the beginning and there are only 5959. 44 directories and 47 shortcuts doesn't seem to make up the diff (which is 32, no clue if thats relevant).

I think we have different versions of data.wz. Maybe that's what the 0x61 is? And why yours is only 0x60. My file table has 6035 entries - 45 directories + 1 becaues the root directory isn't listed = 5991.

The symbolic link thing was a bad guess on my part. They were just trying to save space listing the same string twice. "Ohh... use the string at 0x83948 instead", I can save 3 bytes by linking to strings like that!

I'm sure you know this stuff, but I'll say it anyway. Your immedValue is just a special case of dumpBlock (with obvious benefits) as is your dumpEntryBlock (except for 0x08 which is weird). For dumpEntryBlock, do you think its just they didn't feel like making different codes, or that they're somehow the same function?

I thought that too, but I had trouble getting it to work. dumpBlock and dumpEntry have different interpretations of 0x00 (one is a null, one is a string), and like you said, 0x08 is just weird.

I'm kind of happy with having immedValue as a seperate case, as I think it makes certain things clearer. Since blocks are just descriptions of structs, the main format is: :valuename: then :value:. :Valuename:s can only be immedValues, while :value:s can be a variety of things. It wouldn't make sense to have an image being a :valuename:. But that's just a personal preference, and the two could be merged. Good observation.

The 32 bit ints in immedValue are actually links to strings (so they can save a few bytes, just like in the file table). But valuenames are repeated more often, so they really do save space with it. The filenames aren't repeated enough for any decent savings.

[terasonic]

check it. this is maple's music extractor.



name : terasonic
code : 155018442814BD52

[Savage]

I don't know if it helps...but....looking inside the file ZLZ.dll (uops it'a zlib1.dll)

[quote]
deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly Â

[themoviefund]

Lambda, are you still working on extracting?

[Lambda]

Lambda, are you still working on extracting?

Yes, but work has gotten in the way of finishing it completely during the week. My script can parse the entire file including all images and music. I reworked a large part of it, but now it doesn't print anything out. The other current problem is not handling wide strings (unicode). The unicode text also causes problems when outputting decent filenames for items... You can't really have a filename with tabs or returns in them, but that's what it would try to generate now.

I'll go ahead and post it so anyone else can look at it. Hopefully I'll have more time over Labor Day weekend.

[nicoli_s]

I work for a game DB website and I've been trying desperately to extract info from MS. Great work on figuring all this stuff out btw. I had a small question, I added in a print in the dumpfile function so I could grab the stats from items like I could in your old version, but when it runs, all I see is refernces to the differnet animations for each item, and while the names work fine, the value returned from dump entry value always shows as none for me, im just doing a simple "print "%s is %s" % (str(val), str(value))" where value is the return from dumpentryvalue This is my first time using python so i might be doing something wrong, any ideas?

[Lambda]

I work for a game DB website and I've been trying desperately to extract info from MS. Great work on figuring all this stuff out btw. I had a small question, I added in a print in the dumpfile function so I could grab the stats from items like I could in your old version, but when it runs, all I see is refernces to the differnet animations for each item, and while the names work fine, the value returned from dump entry value always shows as none for me, im just doing a simple "print "%s is %s" % (str(val), str(value))" where value is the return from dumpentryvalue This is my first time using python so i might be doing something wrong, any ideas?

It doesn't return lists of values correctly (like the item stats are: Required Level: 1, Exp: 20, etc..). See extract08type and extract1btype (a few places)... they don't return values ("None"). If you put a return in extract08type, you might get better results.

Good job playing with it as much as you have, it takes confidence to jump into someone else's code and start modifying things.

A big hint: Get rid of the giant for loop at the very bottom. Running through 5000 entries and getting things to work that way is difficult. Just dump the first file and get the prints looking good for that. Also, the code is a little better written now, and you can jump around file entries, if you just want to dump file 1958, you can. You don't have to go through all of them if you just want specific information.

Hopefully I'll have a chance this weekend to write some nice output routines myself.

[themoviefund]

Please hurry By the way, thank you for all this, it's very useful.

[nicoli_s]

awesome,appreciate that, now I can get most of the data I need one question though, have you found any way to get the name of any of the entries?

[masterburner]

First thanks Lambda i got the Pics

so GeeWitz is working with my Mapdump

and i tried MAplox but i get this error

Is something wrong with my OS o_o