This trick requires very basic reverse engineering to accomplish.

TTP Files

ToonTown Pack (TTP) files were registered using a third-party program known as the Toontown Spoofer to change the default look of Toontown Online. Using this program was considered a bannable offense as it utilizes third-party software to illegally modify the game. After TTO closed, revival projects such as Toontown Rewritten allowed native support for content packs that only changed the audio and textures to be used on the game as it allows for user content creation. Modern content packs utilize a different file format, known as *.mf or Mulifiles. These files, which were also utilized by Toontown Online, is akin to a zipped file that the game engine reads from to load assets from.

So, this brings the question: How did Toontown Pack files work?

Dissecting TTP Files

If you open any valid multifile and compare it to any valid spoofer pack file (ttp), they initially look a little bit different from each other. Panda3D Multifiles always start with the ASCII string pmf in the beginning of the file. You can use a hex editor (I use HxD) or any text editor to verify this (I prefer Notepad++ since Notepad has a hard time dealing with extremely large files.) This is known as the file header. Every file has their own unique header usually at the beginning to define how the file is read, encoded, or parsed.

What does the header of a TTP file look like?

Well, it looks like the first three characters CPC are found in every TTP file I’ve opened so far. We can attribute this as the file header for TTP files.

Where do we go now? Since the file headers don’t match, multify wouldn’t be able to read the information correctly (even if trying to rename the ttp file into a mf file!).

Something is a bit odd about TTP files, though… They still have the texture pack data integrated inside of them, and if Toontown natively uses the Multifile system to read assets from, how does the data from a Spoofer pack have the ability to change what the textures look like in game?

Actually, the answer is simple! TTP files have all the required Multifile data embedded inside of them.

Since we’ve already established that pmf is Multifile’s file header (and thus defines how to read through the file), we should look for characters that match pmf inside of a TTP file.

Looks like we have a match! The same pmf and NUL byte appear together right after a series of filepath strings. Highlighted in blue is identical data to the beginning of a Multifile…

Above this data, we can see the series of filepath strings. If we go through the contents of a Multifile, we don’t see anything similar to these strings, so we can suggest that this is proprietary data for TTP files. Additionally, these strings come before the pmf file header data.

Removing the extra junk

We’ve established that a TTP file must:

• Have a way to match the same encoding type as a Multifile in order to work at all.
• Contain all of the custom assets, just like a Multifile would.
• Have a method of reading the contents inside of a TTP file.

That being said, let’s see what happens when we remove everything before we hit the pmf and NUL byte and change the filetype to mf.

It works! Multifile is able to successfully read and extract the contents of our modified TTP file.

Conclusion

TTP files, utilized by the Toontown Spoofer that allowed for custom texture/audio overrides, is a proprietary file format and thus cannot be natively extracted using Multify. However, we’ve discovered that TTP files have Multifile data embedded inside of them, so all we need to practically do is remove the custom TTP data in the beginning and change our file type to be mf!