Researching about Wii U's T6 Fastfile format/behavior

[DarkexMW]

Hello everyone,
I’m currently researching the fastfile formats used by Black Ops 2 on Wii U (exactly trying to run Nuketown Zombies as a test for this to work) and I’ve encountered a structural difference when trying to put things together for the first time.

Context, I’m comparing fastfiles between: PS3 (Version 146 (0x92)) | Wii U (Version 148 (0x94))
When loading a PS3 fastfile on Wii U the engine throws: "Fastfile is out of date (version 146, expecting 148)"

Spoofing the version field (Editing 0x92 to 0x94 in hxd) allows it to pass the version check
However, the frontend freezes during loading (no crash/alert message, just a complete system freeze)

This strongly suggests: 0x94 is not just a version bump, the internal layout differs from 0x92... Offsets, assets and stuff are likely structured differently
What I’ve confirmed is that Wii U and PS3 are both big-endian, but the freeze occurs while loading dlczm0_load_zm.ff (loader of the DLC)

The issue happens even with only the loader .ff present (no ipak)
Comparing a Wii U fastfile (dlc0_load_mp.ff) vs PS3 equivalent shows divergence shortly after the header

I’m trying to identify structural differences between the fastfile format between Wii U and PS3, determine what changed and potentially adapt or reconstruct a WiiU-compatible fastfile

I already have: Dumps of PS3 and Wii U fastfiles, header comparisons, confirmed version spoof behavior
If anyone has:

• Documentation on T6 fastfile internals
• Experience with linkers (and if they could work on PS3/Wii U versions of BO2)
• Knowledge about fastfile versions overall
• Experience modifying Wii U builds of Black Ops 2

I’d greatly appreciate any kind of help or idea... Thanks in advance.

[Laupetin]

hey there,

the fastfile format is unfortunately very heavily based on the memory layout of the games structs which means that any layout change in any asset struct represents a breaking change and makes the fastfile incompatible.
I have not put any effort into researching PS3 or WiiU but from my experience with the differences between PC and Xbox360 and having faint memories of somebody else researching about PS3 structs I would guess it's very likely at least something changed in the structs.

That's one thing, the other is that at least between PC,Xbox and PS3, the key they used for signing fastfiles changes.
While that does not represent a structural issue, the game will not accept any fastfiles that are not signed with the correct private key.
In PC the game will fake a crash when it detects an invalid signature, not sure what happens on other platforms.

That's as far as I can give you insights about WiiU. Like I mentioned, I haven't researched WiiU at all really, just from having experience with the format on other platforms.

[DarkexMW]

Thanks for the answer!
I'll take note of the information here, I remember having the salsa20 keys to decrypt Wii U and PS3 files stored but never tried doing it... I'll take a look

[michaeloliverx]

I have been researching Xbox 360 fastfiles for IW3. I have managed to at least add full unlinking support for all asset types. The assets structs are different in numerous places compared to PC so I have no doubt that the WiiU assets are different as well. A good starting point would be to load the WiiU executable into a decompiler (e.g. IDA Pro) and step through the asset parsing code to determine the struct layouts.

Here is my fork (it is out of date from the main branch now) which may be useful.
main...michaeloliverx:OpenAssetTools:iw3-xenon-asset-parser

Feel free to reach me on discord and ask any questions (link on my GitHub profile)

[DarkexMW]

This may be pretty useful considering that both 360 and Wii U are big-endian! Thanks, I'll take a look