007 Everything or Nothing fails to load

[mborgerson]

See: 007 Everything or Nothing default.xbe. Image header format type 2 doesn't look right for this binary. Trying to parse library features will fail. Needs investigation.

https://github.com/mborgerson/ghidra-xbe/blob/99ca02e412f489910a487d4522eb923d0249b5c5/src/main/java/XbeLoader/XbeLoader.java#L543

See also mborgerson/pyxbe#32

[thrimbor]

The NTSC (md5 80ad342f7ea0d5c01aad8569aab15876) and the german-french PAL (md5 a9cf3049a873c0ae7f70b49cf5b21625) version appear to work fine for me.
Both have a null-pointer in PointerToFeatureLibraries but that's fine because NumberOfFeatureLibraries is zero (both confirmed with hex editor) so the table just doesn't exist.
Header type 2 looks correct to me here, the size matches and the DebugInfo field seems to be valid.

All in all I can't spot any issues at least with these two versions of the game.

[itsybitsypixel]

Just ran into the same issue with the game Animaniacs - The Great Edgar Hunt and it seems to be caused by malformed XBEs.

Both of these games have an imageHeaderSize of 0x184 while having a certificateAddr of baseAddr + 0x178, meaning we'll interpret the XBE header as having values for libFeaturesAddr, libFeaturesCount and debugInfo since imageHeaderSize >= 0x184. But when we go to read these values we'll instead be reading the start of the certificate header and read its size value to be libFeaturesAddr and its timestamp value to be libFeaturesCount, thus causing the program to hang when trying to create a very large amount of XbeLibraryHeader structs at an invalid address.

We can solve this by checking if (certificateAddr - baseAddr) >= imageHeaderSize in XbeImageHeader's constructor and XbeImageHeader.toDataType(), and only read or add the additional variables if so. This will allow us to import the XBE, but...

...there seems to be other problems with these XBEs that cause issues when creating the XBE data in Ghidra. Here's some that that I found while examining the two XBEs:

• They don't seem to respect the size variable of the certificate header and the certificate header will always be 0x1d0 bytes in length, even when size is something other than that.
• The data pointed to by tlsAddr seems to be garbage data from the original EXE or someplace else.
• The kernLibVersionAddr and xapiLibVersionAddr variables seem to be pointing to the wrong address, but offset by the same amount from their "correct" addresses.

There are probably additional problems as well, and I'm thinking these issues were caused by some bug in the original XBE build pipeline.

[thrimbor]

I once again can't reproduce the issue - the only version of this game I've seen is http://redump.org/disc/23898/, and it loads absolutely fine.
The SizeOfImageHeader is 0x184, the DebugInfo value is 0x1E2B44 which points to a valid debug info struct, CertificateHeader is 0x184, and the TLS data is valid. The kernel and xapi library header pointers are correct, too.
No overlap of image header and certificate.

This is starting to sound to me like those XBEs have been corrupted by editing them with some broken tool.

[itsybitsypixel]

This is starting to sound to me like those XBEs have been corrupted by editing them with some broken tool.

Yes, it seems like that's the case. Was too quick to point fingers at Microsoft, and it instead seems to be caused by the XBEs being patched to work for all game regions / media types. Just tried opening, editing allowed game regions, and saving one of the valid XBEs in DEXBE v0.5 and it produced a corrupted XBE with the exact problems specified above. It seems like DEXBE or a similar tool is the likely culprit.