Monster Jam (2007) Potential Mods, "Modding"

[LFGamer2004]

Hello! Me and a friend, were messing with this old game files, but as expected, the files are very hard or impossible to edit "Packfile.dat". BUT, something did hit my attention was, the fact the PS2/Xbox/Wii versions has the 2Player (Split-screen) multiplayer featured, enabled and the PC Port, not. This version I'm using, are the original, with the patch 1.01 installed on.

But, I mean the PC version, has a "Hidden" Multiplayer, that could be supposedely, actived... We've also discovered that the game has Debug material/stuff at your code, but for some reason, it cannot be actived, because the suppose references, was cutted from the final version, IG.

However, after decompile using the ghidra and try different values with Cheat Engine, was possible we got some very interesting results, as you'll see right now! Check the images!

It still doesn't over! We're still trying do reverse engineering from encrypted binary file: "Packfile.dat" which I was able to extract, some textures, using a not very, known tool: "Multi-Extractor 3.3.0"

the remaing of the files are ".hnk" and ".dds" but they're technically encrypted as well. Being impossible extract or view them in any other tool!

Someone do are able to develop a quickbms plugin for files of this game? if yes, let me know! I'll be glad in mod this game! :)

 

 

Edited April 29 by LFGamer2004
Explainations

[murasakiPinku]

This is sick, I'd love to see mods for this game. Want to edit textures, models, music, etc. Looking forward to it!.

[zbirow]

hello, I did the analysis and noticed that the data is separated by !CMP . after it you have 4 bytes of some kind and the rest is data. all start with 78 9C which is the zlib header. which means that the files are compressed. I wrote a code that unpacks all the data to .dat files, after digesting one of the files in hex, I saw the DDS file header. I changed .dat to .dds and the file works. you can see the texture. Currently, that's all I managed to do, I will investigate further to preserve the names and extensions of the files. Link to my github repo with the code to unpack the files. (python)
https://github.com/zbirow/Monster-Jam-Unpack

[LFGamer2004]

Thanks! I hope you be able to extract the 3D models & some parameter files, as: "MaterialAttributes.txt" etc... would be interessing modify these too!

 

[zbirow]

11 hours ago, LFGamer2004 said:

Dzięki! Mam nadzieję, że będziesz w stanie wyodrębnić modele 3D i niektóre pliki parametrów, takie jak: „MaterialAttributes.txt” itd... byłoby interesujące zmodyfikować je również!

 

you mean this txt?
https://github.com/zbirow/Monster-Jam-Unpack/blob/main/chunk_00000.txt

Edited yesterday at 01:25 PM by zbirow

[LFGamer2004]

2 hours ago, zbirow said:

you mean this txt?
https://github.com/zbirow/Monster-Jam-Unpack/blob/main/chunk_00000.txt

Yes! :O

Edited yesterday at 03:30 PM by LFGamer2004

[LFGamer2004]

There a way to, pack the edited files, them into the "Packfile.dat" again? or would be necessary, a creation of a proper tool, to this kinda of modification?

[LFGamer2004]

BTW, what exaclty this file does? 

[zbirow]

1 hour ago, LFGamer2004 said:

Czy istnieje sposób na ponowne spakowanie edytowanych plików do „Packfile.dat”? Czy też konieczne byłoby stworzenie odpowiedniego narzędzia do tego rodzaju modyfikacji?

currently, you still need to examine the Index (see my ReadMe documentation).
Index contains references to addresses where files are, if you give a file of the same size, and there is no shift, then there is no problem, if there is, then you need to fix the Index.

If you want to change the parameters in the txt file (which will not significantly affect the file size), you can use my code for packing packer.py.

In the directory where you have Packfile.dat and Packer.py create a folder "pack", place the modified files there. (the names must match those from the extractor (unpack.py).

you run packer.py, it takes files from the "pack" directory and creates a modified copy of Packfile.dat




and as for the second txt file, it is also from the game data (I used different output names, that's why it's files , not chunk. fmod - it's a DLL library. It's in the main game directory, where the exe file is

[zbirow]

5 hours ago, LFGamer2004 said:

There a way to, pack the edited files, them into the "Packfile.dat" again? or would be necessary, a creation of a proper tool, to this kinda of modification?

Analyzing data today, I learned how it works specifically.
I will be writing new tools.
The documentation on github has been updated.
When everything is ready, I will post here.

[LFGamer2004]

2 hours ago, zbirow said:

Analyzing data today, I learned how it works specifically.
I will be writing new tools.
The documentation on github has been updated.
When everything is ready, I will post here.

Hmm... Question, do this "plugins" would able to open, the one from Console version (PS2 to be more specific), or even Urban Assault ? These games, uses the same file extension (.Dat). but I think that wouldn't be totally possible, due the file complexity. But I'll try it later. Thank you for the info!

[BuilderDemo7]

On 6/28/2025 at 5:52 PM, zbirow said:

hello, I did the analysis and noticed that the data is separated by !CMP . after it you have 4 bytes of some kind and the rest is data. all start with 78 9C which is the zlib header. which means that the files are compressed. I wrote a code that unpacks all the data to .dat files, after digesting one of the files in hex, I saw the DDS file header. I changed .dat to .dds and the file works. you can see the texture. Currently, that's all I managed to do, I will investigate further to preserve the names and extensions of the files. Link to my github repo with the code to unpack the files. (python)
https://github.com/zbirow/Monster-Jam-Unpack

Hello, nice work! By the way thanks to your information about the PAK files I was able to deduce some more stuff based on your information :

# Documentation for Monster Jam .dat archive files (PAK)

# Format: {Offset relative to structure}:{Size} - {Name}
# Secondary Format: {C data type} {Offset relative to structure}:{Size} - {Name} -> {Constant value}

# NOTE: The 'h' after the number means the number is hexadecial.

# HEADER
int 0h:4 - Unique Identifier -> 4B4150h
unsigned int 4h:4 - Whole header length
unsigned int 8h:4 - Number of folders in the whole .pak file

# FOLDER
int 0h:4 - ID
unsigned int 4h:4 - Start address (relative to the start of the file)
char* 8h:? - Zero-terminated string aligned by 4 bytes in the buffer

# FILE
unsigned int 0h:4 - Next folder's file address (if 0 then it's the end of the folder files, relative to the start of the file)
unsigned int 4h:4 - File length
unsigned int 8h:4 - Unknown
unsigned int* Ch:4 - File offset pointer
char* 8h:? - Zero-terminated string aligned by 4 bytes in the buffer

# COMPRESSED FILES DATA
# NOTE: Files datas are aligned by 16 bytes (padding)
char[4] 0h:4 - File compression method identifier
unsigned int 4h:4 - Uncompressed file size?
short 8h:4 - zlib header -> 9C78h

The game kinda lacks the data of number of files in a folder so they just improvised it by putting the next folder's file address in a file data. 

Also the folders and files structures length are dynamic due to the zero-terminated strings which are aligned by 4 bytes in the buffer, when I mean aligned in the buffer, I mean that there will be some extra files to fill the zero-terminated string's space and the length should be always terminated in a number like 4, 8, 12, 16, etc.

[zbirow]

51 minutes ago, BuilderDemo7 said:

Cześć, dobra robota! A tak przy okazji, dzięki twoim informacjom o plikach PAK, byłem w stanie wywnioskować trochę więcej rzeczy na podstawie twoich informacji:

W grze brakuje danych o liczbie plików w folderze, więc twórcy po prostu improwizowali, umieszczając adres pliku kolejnego folderu w danych pliku. 

Ponadto długość struktur folderów i plików jest dynamiczna ze względu na ciągi znaków zakończone zerem, które są wyrównane co 4 bajty w buforze. Kiedy mam na myśli wyrównanie w buforze, mam na myśli, że będą pewne dodatkowe pliki, które wypełnią przestrzeń ciągu znaków zakończonego zerem, a długość powinna być zawsze zakończona liczbą, taką jak 4, 8, 12, 16 itd.

Not everything is completely correct, but a lot of things are good.

directories have separate starting addresses to know what files belong to it, files have the number of occurrences in the Index, and the address to the point in it. (first file: matattr.txt, 23 occurrences in the index one after another, and the address 014CC0).

The index leads to "blocks" where there is data with files (!CMP, PNG).

And 4 bytes after !CMP is the compression size

Thanks for the information about the header and file, I didn't analyze it at all. I preferred to focus on analyzing the files.
The current Documentation is on Github, thanks to your header and file information I will be able to finish it and describe how it works

Edited 1 hour ago by zbirow

[LFGamer2004]

7 minutes ago, zbirow said:

Not everything is completely correct, but a lot of things are good.

directories have separate starting addresses to know what files belong to it, files have the number of occurrences in the Index, and the address to the point in it. (first file: matattr.txt, 23 occurrences in the index one after another, and the address 014CC0).

The index leads to "blocks" where there is data with files (!CMP, PNG).

And 4 bytes after !CMP is the compression size

Thanks for the information about the header, I didn't analyze it at all. I preferred to focus on analyzing the files.

The current Documentation is on Github, thanks to your header information I will be able to finish it and describe how it works

About the .fsb ? 

[zbirow]

About Packfile.dat