00's era game programmer here.
I think there are a few things that you need to understand, this will save you a few hours of research leading to nowehere.
first of all, file extensions are nice for when you are writing to something standardized like a word docx file, or html file. but in game development, especially in the gamecube era, everything was custom made. there is no standard file format for game resources. usually developers will make a file format up, or use a library, to store game resources in. it could be as simple as a concatination of all resource files and adding a lookup table and call it a .bin file (we used to do this back in the day), but it could also be compressed in some way to save space. Even after figuring out the container format (the bin file) you'd still not have a clue if you are looking at png files, or tga, or whatever, unless you get lucky and it's included in the lookup table.
What this means is when you see a .bin file, or any other file, you can't assume that these are the same as the files that you are used to on your computer. the developers could have called the same file .bin, .trashbin, .tldr, the file extension simply doesnt matter, as long as the program can extract whatever is in there.
Like others before me have said, codewarrior is an IDE, and it only runs on old macs or at best windows xp in compatability mode. Additionally, some parts of it require licenses to operate at all, and most likely these will have expired like 10 years ago.
It'll let you write code, but almost never will you find source code on a shipped game. it's almost always compiled into assembly format (not human-readable), and even if you could decompile it, all variable and function names will be random characters, like int x, na, g, ghj, and you will have no clue what the code does, even if you can turn it into C by some miracle, you most likely still wouldnt be able to compile it and run it (if only it were that easy). All homebrew for gamecube that you can find now is written using a completely separate build toolchain (devkitPPC), and the two do not mix. This is why most mods are just that: mods, they use cheat codes to modify the game logic.
I would say this is a much more optimal avenue, since tools for debugging commercial games on gamecube have been available for more than a decade (gcnrd), and used for making modifications to games, to turn into cheat codes.
What complicates things further is that AC isnt even a gamecube game, so there is most likely a layer of gamecube code wrapped around n64 era code (only nintendo itself was allowed to do such hackish things, of course).
I do hope you get somewhere with this, but gamecube era tooling and apis weren't exactly easy to use.
regarding this static file you mention, most likely it's a lookup table with filenames and references to where to load it from, and the actual file embedded somewhere in there. most likely it's a filename, an offset in bytes from the start of the resources chunk. the filename serves as a key to look up the actual files in a resource dictionary, like what i described with the .bin files earlier.
considering protection wasnt high on the priorities list back then, it's likely that the resources are in the static file in raw binary format.
You might be able to get them out and change them, but decoding, verifying it really is a resource container, and re-encoding that static file would be my first priority if i were you.
