Guild Wars .DAT File

[RavynousHunter]

Huh... Didn't notice that until I took a closer look... My attentiveness seems to take a hit after 2am.

[FurryFan]

Has anyone been trying to crack the 3d format?

Yes, in the sample FFNA files that were posted there is a 3d model in it.
The two files both contain a Legs wearing high heels apparently. However the file from the Server is smaller but still has the same base mesh and 4byte float Vertexes, but its, Normal mapping, And texture Mappings appear to be signed Integers not floating points at the end of the file. The FFNA file from the data file has regular 4byte floats for textures and normals. Here are pictures:


Using signed binary integers as textures coordinates is something that mostly really old pre-2000 computer games use, so I suggest that this mesh, is just a low Lod mesh used when they are a lot of meshes on screen.

[BlackDragon]

Hey, nice find. I haven't looked at this in ages but maybe we can get a little close now huh?

What file was it? What were the header bytes?

BD

[FurryFan]

Hey, nice find. I haven't looked at this in ages but maybe we can get a little close now huh?

What file was it? What were the header bytes?

BD

"Lej" posted it way back on page 11, in 2007, The files are at
download/file.php?id=1393

It is just 3 different versions of file "50584".
The smaller decompressed version from the sever begins with:
(66 66 6E) [ffna]
(02 B8 0B 00 00 2F 18 00 00 26 00 00)
(00 00 00 00 00 09 01 00 00)
(F0 95 B2 D6 88 15 B8 6C 00 00 00 00 00)

The "26" probably almost certainly refers to the real beginning of the file, because the rest of the file matches up with it especially if you display 24 bytes in each row in the hex editor.
Then there are some unknown bytes and the floats,
.6999999999 and 1.79999999 which are almost exact fractions probably a scaling factor.
Then more unknown bytes followed by (E2 02) [738 in decimal]
which is the number of bytes in the face list, however the face does not begin until 0X24 bits later.
Face list is:
[Vertex#1, Vertex#2, Vertex#3]
Then without a break the Vertex list
Followed by some type of Normal and texture mapping. It might by compressed but there is still a slight pattern: when looked at in rows of 24, some rows have only values higher than C0, while other rows contain values only smaller than 80.
Next in the file are two (DXT?) textures, which both begin with the text "ATEXDXT"

The bigger file from the guild wars data file, does not have actual textures, but does have Normal and Texture mapping, also the Face list begins 0x32 bytes after the bytes that show how long it is and the header is:
(02 A0 0F 00 00 F5 2C....) after the text "ffna"
I need more files to test, the decompressers posted give me an error message when I start them up on my dat file.

[BlackDragon]

I still have the source here. What is the error you are getting? What OS are you using?

BD

[FurryFan]

I still have the source here. What is the error you are getting? What OS are you using?

BD

I got a different decompression program to work. Thanks for asking though.

[BlackDragon]

I still have the source here. What is the error you are getting? What OS are you using?

BD

I got a different decompression program to work. Thanks for asking though.

Anyone done anymore work on this? Or should I dust off my debugger

--BD

[mqstout]

What do I have to do to convince you to dust off your debugger?

[FurryFan]

I still have the source here. What is the error you are getting? What OS are you using?

BD

I got a different decompression program to work. Thanks for asking though.

Anyone done anymore work on this? Or should I dust off my debugger

--BD

What I did was use the ATEX (guild wars texture format) converter that someone else wrote, and match the mesh files up that have similar file numbers, it worked for a bird model, and some others but not every mesh had a similar number to the mesh's texture.

I think that we can get file names/hashes from Guild Wars RAM when the game is running. For example you could do a pointer search for a NPC's name that is on screen, and see what model file number is pointing to the NPC's name. However the program "Cheat Engine" won't attach to the guild wars process, even if disconnect the internet first.

BlackDragon, you wouldn't know by any a program that can do a memory dump, that keeps the absolute offsets intact in one huge 2GB file, so that you could still search for Pointers?

[BlackDragon]

No, I do not know of a program that does that.

The only filenames I ever saw where for the maps, and they used an internal naming format that was somewhat convoluted. As a matter of fact, there is an old interview on the net where one of the developers talks about how they named the maps. I think it had something to do with the music.

If you use the GWDAT extraction tool, you'll see "hash numbers". Those are actually "file numbers" and is how the game access the files internally. Originally I thought that there would be a "master file" for each area that would have pointers to the other files but I never actually found one. What seems to be the case is that those file numbers are hard-coded into the executable itself. In fact, when you hit a new area you can see the game loading the ffna files by putting a dubug point on the ecx register. The executable useses ecx, then goes through huge amounts of error-checking before loading the file. Simply adding breakpoints to reads of "SetFilePointerex"in kernel32 let's you follow what is going on.

Two issues I always ran into is that:

#1 My favorite debugger, OllyDBG doesn't handle multi-threaded programs well; it would deadlock on the current thread a lot when the game would access a thread other than the current one
#2 The game uses a lot of high-level language containers (like linked-lists) that added a huge amount of bloat to the assembly code which made it time-consuming to get to the actual code that we would be interested in.

You can get around both of these. #1 can be worked around by breakpointing out of the thread completely (as the example above in kernel32)

and #2 just takes patience lol.

But with the fact that those model files have the vertexes in them and they can be processed is progress. As I mentioned a while ago it's been years since I've done and gfx programming.

I run Linux now, and ollydbg crashes in Wine, but I might just dual-boot for a while and do some more work on this.

BD

[mqstout]

http://wiki.guildwars.com/index.php?tit ... id=2016377

Not sure if this is insightful or useful to anyone, but an A.net rep mentions AMDL files. Googling "amdl" doesn't seem to get me anything relevant. But, I figured I'd share.

[BlackDragon]

Those are MDL files. The "A" stands for "ArenaNet". They do that with all of their filetypes because some of them are customized.

They use "Granny" as a development tool but change the format some as far as I know.

BD

[chrisvj]

I am not sure if it is any help, but Hex Editor Neo can be used to view the file in assembly language, however it can not load the whole thing at once. You just use the unassembler