XeNTaX

Yeah, the ffna's and also the "unsorted" are data of some sort. I still think that the ffna files have to have pointers to other files that tell the game what to load for a specific instance.

But, I'm looking into it more to see what is going on.

BD

some of the unsorted files are actually materials, those files start with AMAT, and it looks like they contain dx9 shaders and some other stuff.

I was looking through the unsorted files a bit this evening. I had a script separate out the AMAT files and I made a list of them. I also made a list of those that obviously contained textual information in the game. I only got up to about file number 40000 though. Some of the text is interesting. There are skill descriptions of removed skills (keyword: REMOVE all caps), and some skill descriptions that seem to be like they're already in there from the up-coming expansion.

I'll keep poking casually with these. I like text. Might start trying to correlate files of different languages.

I guess I can't attach text files, so wastefully I zipped them.

I've finished a first (and probably quite buggy) version of my GUI. It can display all the textures (except .dds files), all other files are shown in a hex editor, and of course the files can also be exported.

I only tested it on Vista, but I think it should run on XP too.

Source is included (you better not look at it though, it's rather ugly ), but please don't distribute any modified versions if you make any changes, send those changes to me instead and I'll add them.

Get it here: http://www.raechaer.de/GWDatBrowser.zip


Oh, and does anyone know of an easy way to display the .dds files (other than using Direct3D and using them as textures)?

Wow, nice job on the gui!
The dds format is pretty simple, if you look in it you'll see it's uncompressed data. Altho I think it can store several images (different mip levels etc)

Here are the things I miss at first glance:
-the uncompressed size is not displayed in the listing
-the first flag (0x00 or 0x80) is the compression flag
-the alpha in the image display seems incorrect, there should be an option to turn it off
-we really need an mp3 player, bass.dll should be easy to include in the project

Yeah, good job Irina.

I have a question:

I haven't had time to look at the code yet, but what is the "section" and "ID" columns for?

And do you process the hash table?

BD

@BoyC:
I've found some code that reads dds files, but it seemed quite complicated so I didn't take a closer look. If it's really just uncompressed data it might not be as hard as I thought though.

-Displaying the uncompressed size should be easy, I'll add that in the next version. I basically just display all the stuff that your app displayed on the command line.
-Hmm, images with alpha are displayed just fine for me (did you see that you can change the background of it in the context menu?). Can you post a screenshot of a it? Not sure if I can tell GDI+ to draw the image without alpha, but I'll check.
-mp3 player will be added, I just wanted to release a somewhat working version asap

@BlackDragon:
All the "decoding" of the GW.dat is done by BoyC's Code, so he'll have to answer that. But I don't think he's processing the hash table.

"Section" is supposed to be sector. The bigfile consists of 512 byte blocks as you know, that number is the number of the start sector of the file.
ID is the value that's in the mft and appears to be sequential when you add the hash table in there. The hash table is not processed only loaded.
I think that's supposed to be a unique file ID as there's nothing else in the mft to uniquely identify a file by.

Edit:
The IDs also seem to show a chronological order of the game being built if you sort them, so it's a safe bet these are the references the game uses to identify and update unique resources.

Oh and irina: the amp files are also mp3 files so add them to "sound", and you should add the files starting with "AMAT" as "material"

As for the alpha thing, you could just add an option to redisplay the image with every alpha byte set to 255, that's it :)

Here's a new version: it now also displays the uncompressed size, it has a very ugly looking player for the mp3s and I also fixed a few bugs (and probably introduced new ones ).
No source this time because it's late and I'm lazy, if anybody actually wants/needs it just tell me and I'll upload it.

It's minor, but I found a pattern in a bunch of the unsorted files that contain text/strings. The 2nd to last byte seems to indicate language. While it's not perfect (especially with English), it really feels like there's something to it.

decimal values
0 english
1 korean
2 french
3 german
4 italian
5 spanish
6 chinese traditional
7 chinese simplified
8 japanese
9 polish
10 russian
17 bork

I ran a few tests changing language options in GW and re-extracting the preference files, and they check. English in preferences is 0, french is 2, bork is 17 (x11), etc. A couple dozen text-containing files I found check out with this. Most of the files I found with German text had x03 as their 2nd to second to last byte, and those with bork had x11 as their second to last last byte...

There are, however, some that don't (particularly english-text-containing ones).

Up to about 45000 giving quick look-throughs to unsorted files for text.

Edit/Addition:
The following files all appear to be the same file but for different languages:
131188,130964,130962,130966,130834,130968 (it's a list file of armor names starting with Luxon Gloves and Luxon Hose. They all end in 002E00xx42 where XX is the language. The first characters differ as well.

I've been working on decoding some of the "unknown" file formats as well as the ffna files.

ffna files with a type of "2" (which is the byte right after ffna in the raw file) are model files btw. Someone mentioned somewhere else that GW uses the "granny" software for building models in-game, so if anyone knows anything about that let us know.

Anyway, I have two coding questions. I use OllyDbg (because it is free, and I can't afford IDA Pro) so my questions related to this.

Does anyone know how to set an OllyDbg breakpoint if a certain range of memory is accessed? the ffna files build another list, but also do this weird table-based processing and I'm trying to find out if the tables are built dynamically or are hard-coded, because the data in them doesn't make any sense yet.

Also, is there a way to make OllyDbg STOP the gw executable from creating threads and keeping everything (for debugging purposes) in a single thread?

BD

Granny refers to Rad Game Tools program:

http://www.radgametools.com/granny.html

Awesome job guys on all the stuff!

BlackDragon wrote:Does anyone know how to set an OllyDbg breakpoint if a certain range of memory is accessed?

In the memory dump select the memory range you want to have the breakpoint on, right click and it's in the menu somewhere.

BlackDragon wrote: Also, is there a way to make OllyDbg STOP the gw executable from creating threads and keeping everything (for debugging purposes) in a single thread?
BD

That would be a no go from an engineering point of view - in order for the client to run in single threaded mode you'd most probably have to rewrite the whole thing.

Ok, wild guess here: what if the ffna files stand for "ArenaNet File Format"? If they wrote 'anff' for the ID string in the source, it'd be reversed because of the endian order... :)

I'd think it probably is "ArenaNet File Format".

I'm working on decoding it now.

BD