Custom Save Blocks

After some research, I’ve figured out how to customize the save file header information for both AWL and AnWL.

Each game has a file named wlp1.rel, which is a relocatable module (similar to how .dll files function for Windows programs). This file has the information which dictates the header info when creating or overwriting a save file.

This information includes the chapter names, the save filename, the game / save title, and the banner / icon to be used.

By manipulating this file, I’ve changed the game / save title for each game to HM: APL (for the wlw mod) and HM: AnPL (for the mlm mod).

I’ve considered changing the filename (originally bokujyo4.dat or bokujyoA.dat, depending on the game), but changing this would invalidate any previous save files for users of earlier alpha/beta builds of the mod.

Save Block Textures

In addition to modifying names / variables in this file, we can also modify the textures used. While I had already modified banner_card.tpl, I decided to try my hand at modifying card_icon.tpl. This file is a bit trickier since it uses a texture format that utilizes pallettes.

The important thing to note hear is that all of the individual textues must utilize the same pallette for the textures to render properly when displayed by the console hardware.

It’s also important to note that the order the textures are displayed is in bouncing order. That is to say that they go in order of 1->2->3->2->1->2->3, as opposed to a normal GIF loop order of 1->2->3->1->2->3. This is most noticable when seeing how the dog mouth opens / closes on the otiginal save icon

Standard Loop
Bounce Loop

Creating a new Save Block Texture

I started by deciding what I wanted to make for the new save icon. After some internal debate, I decided on using the blue feather (the symbolic item for proposing to one of the romance options) with a LGBT flag background. I created a version with a standard 6-stripe rainbow flag (1979 6-stripe variant), as well as one with the lesbian flag (2018 5-stripe variant).

I also created versions with the Philadelphia pride flag (2017 8-stripe variant) and Progress flag (2018 variant). While these show up ok with increased internal resolutions (i.e. emulator), they appears blurry / pixelated on original interlaced resolutions (i.e. original hardware). For this reason, I have made them available as optional, which can be used to replace the card_icon.tpl texture file on the disc.

Blue Feather (from commonall.arc.clz\symbol.tpl\Texture5), 1979 Rainbow Flag, 2018 Lesbian Flag, 2017 Philadelphia Flag, 2018 Progress Flag
Progress and Philadelphia Pride Flag Mockups

Philadelphia Flag card_icon.tpl [DOWNLOAD]
Progress Flag card_icon.tpl [DOWNLOAD]

To ensure that all images used the same pallette, I saved each texture as a single-frame 256-colour .gif file. When saving the first texture, I saved the generated colour table as a Photoshop palette. Then, when I saved the second and third textures, I loaded the colour table from the previously saved palette file. This would ensure that all three saved .gif image files had the same embedded colour table / palette.

When loading a .gif with an embedded colour palette into BrawlBox, it will give the option to import the palette. By selecting this option when replacing each texture in the card_icon.tpl file, it ensures they’ll all match.

Once the game is loaded with the edited wlp1.rel, card_icon.tpl, and banner_card.tpl files, and the game diary is re-saved, the changes will take effect.


New Discord Server for Harvest Moon / Story of Seasons Translation Projects

It’s recently come to my attention that some other projects are now using the tutorials I’ve written on this blog. This was always my intent and the primary reason why I’ve been documenting all of my findings while researching AWL.

I’ve now created a [Harvest Moon Translations Discord] where people can collaborate and discuss translating AWL, as well as other HM/SoS games into various languages.

I hope that having a dedicated server will offer people a common place to help work on these projects, and get in touch with others who might have helpful expertise, whether it’s knowing another language, or technical knowledge about the game in question.

Currently I’ve created channels for a few AWL, FoMT, and DS projects, but more will be added as they come up.

If you or someone you know would be interested in helping translate some of these games, feel free to [join]!

Save File Checksums

After some research, we’ve determined that the save files for A(n)WL use a checksum to verify data integrity.

If the save data is modified and this checksum isn’t accounted for, a data corruption error will be presented when attempting to load the data.

This checksum is a 4-byte (32-bit) value stored at 0x40

Note: save files can be when using Dolphin emulator are located in “C:\Users\{USER}\Documents\Dolphin Emulator\GC\USA\Card A\”

The value can be calculated by taking all of the data after the checksum position, i.e., 0x44 to the end of the save file, and then calculating the checksum using the CRC32_bzip2 algorithm.

I’ve found that the easiest way to accomplish this is by saving the save data (from 0x44 onwards) to a seperate file (in this case, I’ve named it as hashtest.bin)

Once created, the save data (hashtest.bin) can be analyzed using a supported tool such as Jacksum. For Jacksum, I used the following hash command:

java -jar jacksum.jar -a all -F "ALGONAME{i} (#FILENAME) = #CHECKSUM{i}" hashtest.bin

Then just look at the output of the crc32_bzip2 hash and voila! It should match the previous 0x40 checksum value.

Using this knowledge, we can now edit various aspects of the save file including:

  • Character names
  • Animals
  • Items
  • Buildings (e.g. milking room, seed maker)
  • Money

The process for making these edits should be fairly straightforward

1. Extract the save data from your GCI file (from 0x44 onwards) and save it to a seperate file (e.g. hashtest.bin)

2. Find the value(s) you want to edit (e.g. money) and edit them

In this case, my money value was previously 999999 (hex = 0F423F). The value seems to be stored at 0x1962e (in hashtest.bin). We’re gonna try changing this to 123456 (hex = 01E240).

3. Calculate a new checksum of your save data using Jacksum (as shown above) by analyzing your seperate save data file (i.e. hashtest.bin)

CRC32_bzip2 checksum of our new data (money = 123456) is 34efd17e

4. Open your original GCI, overwrite with your new checksum at 0x40

5. Overwrite the save data fro 0x44 onwards with your newly edited data (copied from hashtest.bin)

6. Save your new GCI file



As an alternative to Jacksum, you can actually calculate the checksum right from within Hex Editor Neo (if you’re using a different hex editor, you’ll need to follow the Jacksum directions above).

Simply go to View -> Tool Windows -> Checksum

Then add, select the “Add Algorithm button to create an algorithm with the following settings:

  • CRC-32
  • Initial Value: ffffffff
  • Polynomial: 4c11db7
  • XOR Out: ffffffff
  • Uncheck Reflection In
  • Uncheck Reflection Out
  • Name: CRC-32/BZip2

Once saved, simply highlight the affected data in your .gci save file (i.e. 0x44 to the end of the file). Then, select the “Selection Only” option from the Checksum tool window, and the appropriate value should be generated in the CRC-32/BZip2 row.

Voila! You can now modify any data directly within the GCI file, regenerate the checksum (by selecting data from 0x44 to the end off the file), and then insert the new checksum (at 0x40).

Special thanks to James for figuring this out.

Tutorial: Extracting Raw Texture Data and Calculating Hash Values From TPL Files + Naming PNG Image Files As Per Dolphin Standards

I’ve been playing around with the “Dump Texture” feature in Dolphin recently.

When the emulator dumps textures, it creates a file name that includes a hash of the texture data. This hash uses the xxhash64 algorithm.

I’ve found that, using information about the TPL file format, I’m able to extract the raw image data from the TPL files.

Once I extracted this data (via manually copy/pasting in a hex editor), that I’m was able to feed it into the xxhash64 algorithm. I used QuickHashGUI for this.

To my surprise, this actually worked and the hashes matched!

Extracting the image data from the first image contained in the logo.tpl file (the Marvelous logo) and comparing hash values to the dumped Dolphin texture filename.

I’m going to try creating a QuickBMS script to extract raw image data from TPL files to somewhat automate the process.

Eventually this means that I should be able to generate hashed filenames for every texture on the game’s disc. This bypasses the need to typically play through and manually come across every texture in-game.


I’ve created a QuickBMS script that can take any input TPL file, and output the extracted raw texture data.

endian big

idstring "\x00\x20\xAF\x30"

get filesize asize
get openedFile filename

get numberOfImages long
get imageTableOff long

if numberOfImages == 1
    goto imageTableOff
    get imageHeaderOff long
    goto imageHeaderOff
    get height short
    get width short
    get imageFormat long
    get imageAddress long
    set name string openedFile
    string name - ".tpl"
    string name + "_Texture0_"
    string name + width
    string name + "x"
    string name + height
    string name + "_"
    string name + imageFormat
    string name + ".bin"
    math filesize - imageAddress
    log name imageAddress filesize
    for i = 1 < numberOfImages
        goto imageTableOff
        get imageHeaderOff long
        get null long
        get nexImageHeaderOff long
        goto imageHeaderOff
        get height short
        get width short
        get imageFormat long
        get imageAddress long
        goto nexImageHeaderOff
        get null long
        get null long
        get nexImageAddress long
        set imageSize long nexImageAddress
        math imageSize - imageAddress
        set name string openedFile
        string name - ".tpl"
        string name + "_Texture"
        set texNum long i
        math texNum - 1
        string name + texNum
        string name + "_"
        string name + width
        string name + "x"
        string name + height
        string name + "_"
        string name + imageFormat
        string name + ".bin"
        log name imageAddress imageSize
        math imageTableOff + 0x08
    next i
    goto imageTableOff
    get imageHeaderOff long
    goto imageHeaderOff
    get height short
    get width short
    get imageFormat long
    get imageAddress long
    set name string openedFile
    string name - ".tpl"
    string name + "_Texture"
    math numberOfImages - 1
    string name + numberOfImages
    string name + "_"
    string name + width
    string name + "x"
    string name + height
    string name + "_"
    string name + imageFormat
    string name + ".bin"
    math filesize - imageAddress
    log name imageAddress filesize

Once extracted, these files can be hashed with a tool (e.g. QuickHash GUI) using the xxHash64 algorithm.

Combining the data from the script with the hash will provide you with the full filename that Dolphin would normally generate.

Comparison of BMS-extracted texture data vs Dolphin-dumped files

Once you’ve determined the file hashes, you can extract the textures from your TPL as PNG files using a tool like BrawlBox or Wexos’s Toolbox.

The naming convention will be as follows:

  • Naming Type – denotes the texture naming scheme used by Dolphin, should always be “tex1”
  • width x height – dimensions of the original texture, can be found in the file output from the BMS script above
  • hash – xxHash64 of the raw original texture data (as output from the BMS script once fed through a tool such as QuickHash GUI)
  • format – original texture image format as named in output from the BMS script above
  • Output file extention – output image file, should always be “.png”

Here’s a visual demonstration of the file naming convention, and where the different parts can be found.

Extracting a texture to a png image using BrawlBox, using naming information provided by QuickBMS + QuickHash

Update #2

After going through every CLZ, ARC, and TPL file, I beleive I’ve been able to dump/rename (almost) every texture in the game.

There are a total of 4115 unique texture images from Harvest Moon: A Proud Life (lesbian version).

I’ve compiled all of these dumped textures into a Dolphin-compatible pack, which can be downloaded [here].

Cutscenes / Trigger Events

Cutscene / Event Files

After a bit of digging into the file formats of A Wonderful Life, I was able to figure out which files contain data for cutscenes.

The files in question are .sb script files. The versions of these files utilized in-game are compressed using CLZ-compression, resulting in .sb.clz files.

There are a few places where these files can be found.

  • .sb debug scripts at disc:/test/Script/
  • Unnamed CLZ-compressed versions of the above debug scripts (i.e. .sb.clz files) contained in disc:/test/Script/test.arc
  • Unnamed CLZ-compressed chapter-specific events (e.g. romance cutscenes, son cutscenes) in disc:/Chapter#.arc
  • Unnamed CLZ-compressed common events (i.e. can be triggered in any chapter) in disc:/Common.arc

The unnamed Chapter and Common events can be determined by looking at the legend in disc:/test/text/EventOCC.txt. As an example, here is disc:/Chapter2.arc, with it’s corresponding event legend.

Replacing Events with Debug Scripts

Using this knowledge, we can compress some of the debug scripts using Sukharah’s CLZ Tool, then can import them into the Chapter or Common files, replacing a previously-defined event. This is done by right-clicking the intended event in the destination .arc file, then selecting “Replace” from within Wexo’s Toolbox. Then, when the game wants to trigger the normal event, it will trigger the newly replaced debug event instead.

Here is an example where I replaced in disc:/Common.arc with the (compressed) debug script loading instead of

The main downside of the debug scripts is that almost all of the debug text is untranslated Japanese. The above example was translated by myself by modifying debug.mes.

Here is an example using the default untranslated dialog.

Accessing Galen/Nina’s house during Chapter 2

Heart Event Cutscenes

While I could manually extract every bachelorette cutscene from Chapter1.arc and import it to replace 8009_link as above, this would be fairly time consuming. Fortunately, there’s another way.

The test script folder contains a handy script,

When compressed, imported, and triggered, this script will open up a menu, from which you can select any of the possible bachelorette cutscenes including heart events, matchmaker scenes, reverse proposals, and successful marriage events.

Here’s an example loading one of Muffy’s heart events.

Muffy Heart Event 4

Note that these cutscenes can only be loaded during Chapter 1. Attempting to load them in any of the later chapters will result in a crash.

Dialog Editing with Sukharah’s MES Unpacker

Introducing Sukharah’s MES Unpacker

After months of painstakingly editing dialog using a combination of Harrison’s MES Editor, Hex Editing, and Spreadsheets, I’m happy to say that we now have a much easier method for editing dialog (mes) files from Harvest Moon: A Wonderful Life and Another Wonderful Life.

Sukharah, the brilliant individual behind the CLZ Compression Tool, has created a new tool for manipulating MES files. This tool has been aptly named the MES Unpacker (although it can also repack).

Compiling the MES Unpacker


The tool is released as source code, meaning you’ll need to have a C++ compiler such as g++ (included with MinGW, which can be installed using the mingw-get-setup.exe installer from the MinGW releases page.

Once you have MinGW/g++ installed, it’s just a matter of downloading the MES Unpacker repository, and building the program using your terminal of choice.

Compilation Options

There are 3 main modes you can use while compiling the MES unpacker.

The normal mode uses a fairly basic compilation command:

g++ -o mes.exe -std=c++11 -iquote header "source/main.cpp" "source/MES.cpp"

The next mode, known as ddupe, will allow the app to group sequential duplicate messages together in the final repacked .mes file. This is needed for certain dialog files (e.g. muumuu.mes) that approach the 73,376-byte file size limit. Attempting to load a .mes file larger than this in-game will result in a crash.

g++ -o mes_ddupe_seq.exe -DDUPE -std=c++11 -iquote header "source/main.cpp" "source/MES.cpp"

The final mode, known as ddupe2, will group together all duplicate messages from anywhere in the dialog file. This breaks compatibility with Harrison’s MES Editor, but should otherwise work in-game. It’s not advised to use this option unless you’re unable to get below the 73,376-byte limit after using ddupe.

g++ -o mes_ddupe2_nonseq.exe -DDUPE2 -std=c++11 -iquote header "source/main.cpp" "source/MES.cpp"

Precompiled MES Unpacker (Windows 10 only)

I have also created a compiled version. The limitation of this precompiled version is that it’s limited to Windows 10 systems, since that’s the type of system I compiled it on.


mes.exe – Standard compilation

This version is recommended for almost all .mes editing use cases

mes_ddupe_seq.exe – Compiled with -DDUPE flag

This version is recommended for certain large .mes files that approach the 73,376-byte filesize limit.

e.g. muumuu.mes, son_talk.mes

It’ll group any sequential (appearing directly after one another) duplicate dialog messages together in the final output .mes file.

mes_ddupe2_nonseq.exe – Compiled with -DDUPE2 flag

This version is experimental. It’ll group any duplicate messages from anywhere in the dialog file.

This is only recommended if you’re having difficulty outputting a .mes file below the 73,376-byte file size after using mes_ddupe_seq.exe, which is possible if you plan on editing Muffy’s dialog (muumuu.mes).

Using Sukharah’s MES Unpacker


Once you’ve compiled or downloaded the MES Unpacker, using it is fairly trivial.

Simply place your .mes file (e.g. badog.mes) in the same folder as your compiled program. Note this folder must also include the tool’s “data” folder and it’s contents.

Then, launch a command prompt in that folder. The simplest way to do this is by typing “cmd” in the navigation bar and pressing Enter.

From there, just type in the appropriate unpack command.

mes_program unpack file.mes file.txt

Where mes_program is either mes, mes_ddupe_seq, or mes_ddupe2_nonseq and file.mes is your dialog file.

Unpacking badog.mes and muumuu.mes using their respective builds.

Editing the TXT files

After you’ve run the commands, you should have some new text files in your folder.

You can edit these using any tool you like. Personally, I prefer Notepad++.

For this example, we’ll be replacing one of Dr. Hardy’s lines (badog.mes).

Simply locate your desired line in the appropriate text file, and edit it at will. Note that a single line (not counting actions like {PAUSE}, {WIPE}, {SOUND}, etc.) can only be 21 characters (letters) long. Anything beyond that will cause issues when displaying in-game.


Once you’ve edited and saved the txt file, simply run the appropriate pack command.

mes_program pack file.txt file.mes

Where mes_program is your build of the tool, and file.txt is your edited dialog text file.

This will overwrite the mes file in your folder

You can then put the newly packed mes file back into your ISO or game folder, replacing the previous one.

From there, the game should load your new dialog in place of the old one.

And voila! You’ve successfully edited dialog.

Player Model Swapping

Now that I’m able to access the contents of the previously inaccessible CLZ files, It’s time to experiment with model files.

My first test was to decompress the mainchapter archives (e.g. mainchapter0.arc.clz), then extract the boy archives from there (e.g. boy_0.arc).

Then, I went about swapping the GPL files (e.g. boy_0.gpl). Based on my previous research, these should contain all of the 3D model data needed.

My first test at importing the girl model into AWL was… less than successful.

All hail the nebulous genderless void!

But at least the game didn’t crash, so that’s a start.

After some further tests, I found that I needed to swap all of the girl/boy-associated model files (act, gpl, skn, tpl, and tam) with their boy/girl counterparts.

Time to replace some additional data!

After replacing the model files, replacing boy_0.arc and girl_0.arc in the corresponding mainchapter0.arc files with their updated versions, and repacking those into their corresponding mainchapter0.arc.clz formats, it was time to test them out.

To my surprise, the models worked with little to no issue.

We now have the female model in AWL and male character in AnWL!

Note the mirror (AnWL) or lack thereof (AWL)

The animations seem to rig fairly well to each character, with a few exceptions (e.g. standing still while holding an animal such as a dog or chicken as the girl in AWL will cause the ponytail to do weird things).

I’ll be doing some more testing regarding the animations, with the hopes of fixing any discrepancies (e.g. the above animal holding glitch, the wider/narrower stance difference between the characters, etc). I know James in the Discord has been very active in experimenting with the character animations lately.

CLZ Decompression / Recompression

Sukharah’s CLZ Compression Tool

Recently a wonderful soul who goes by Sukharah has managed to reverse-engineer the CLZ compression format used by AWL and AnWL.

They’ve used this knowledge to create a CLZ Compression Tool, which can be used to decompress clz files, as well as recompress them.

This is beyond amazing and opens up the project to begin work on models, animations, textures, and so much more.

Compiling / Downloading the Tool

The tool is meant to be compiled using a C++ compiler (e.g. g++). You can follow the instructions on Sukharah’s GitHub to compile it yourself.

Precompiled Version

For those not experienced in compiling programs, I’ve compiled a version that can be downloaded from [here]. I’ll be posting any newly compiled versions on the HMAPL Discord as Sukharah continues to develop the tool.

Note that this pre-compiled build will only work on Windows 10 and up, since that’s what I used to compile it.

Using the Tool

The utility is fairly straightforward.

I found the easiest method was to put your desired CLZ file in the same directory as CLZ.exe.

Then, open up a command prompt in that directory (e.g. type “cmd” in the Windows Explorer navigation bar).

Then, in the command prompt, execute the command:

 clz unpack input.file.clz output.file
clz unpack mainchapter0.arc.clz mainchapter0.arc

In the above example, I decompressed mainchapter0.arc.clz into it’s native arc format.

Quirks of Decompressed U8 Archives

The decompressed U8 archives (.arc files) seem to display improperly when viewed in BrawlBox (my former go-to arc tool).

Data sequence mismatching, resulting in seemingly duplicate data

As we can see from the above screenshot, the contents of boy_0.arc (embedded in mainchapter0.arc) are displayed before the actual boy_0.arc descriptor. This can cause mismatch/corruption issues when attempting to edit the files using BrawlBox.

After a bit of trial and error, I’ve found the best tool to work with these decompressed U8 archives is Wexos Toolbox

No more weird data sequence mismatches

Now that we’re able to decompress CLZ into ARC and modify these ARC files using the appropriate tools, we can play around with models, textures, and so much more.

Recompressing CLZ Files

While decompressing is one step, we need to recompress the files back into CLZ archives for any hope of the game reading them.

Fortunately, Sukharah built this functionality into their tool as well.

Unfortunately I had some issues using the “pack” function (output files would crash when loaded into AWL), although I believe this issue has been resolved in a recent revision of the tool.

So I ended up using the memory-optimized pack method.

clz pack2 input.file output.file.clz
clz pack2 mainchapter0.arc mainchapter0.arc.clz

Files compressed using the pack2 function worked perfectly, albeit with slightly longer load times than the original AWL files.

Exploring the GameCube Service Disc gpl models

Preliminary Analysis of gpl files on the Service Disc

After a bit of research on gpl models, I’ve been lead to the Gamecube Service Disc v1.0/03.

Upon analysis of this disc, I’ve found that it contains gpl files created using version 12012000 of the geometry library (same as the Dolphin SDK), as well as version 6012001 (same as A Wonderful Life).

When booting the disc normally, it seems to load the v12012000 gpl files (e.g. disc:/gxDemos/CarDemo/f50.gpl) for the default Car Demo program (disc:/CarDemo/cardemo.dol).

Attempting to Swap Models

However, I can get it to load the 6012001 versions (e.g. disc:/CarDemo/f50.gpl) by replacing the main executable on the disc (disc:/main.dol; naming might vary depending on the tool used) with a special version of the Car Demo program (disc:/ntd/cardemoN.dol).

With this in mind, I should be able to (in theory) replace some of the models in the cardemo with files from AWL.

E.g. If I were to look at bass.arc from AWL, it contains all of the needed files (an act, a gpl, and tpl).

If I were to extract these files and adjust the files on the service disc as follows:

  • rename disc:/CarDemo/f50.act to disc:/CarDemo/f50.act.backup
  • rename disc:/main.dol to disc:/main.dol.backup
  • copy disc:/ntd/cardemoN.dol to disc:/main.dol
  • copy bass.act to disc:/CarDemo/f50.act
  • copy bass.gpl to disc/CarDemo/bass.gpl
  • copy bass.tpl to disc/CarDemo/bass.tpl

It should load the bass model when booting the disc, instead of the default ferrari.

However, it seems that the new model (in this case, bass.gpl) does not load correctly.

The bass model should be above the rectangular shadow in the middle.

I’m not sure why this is currently the case, but I plan on doing some further tests as I can.

Why a lot of AWL models won’t work

A lot of gpl files on the root of the AWL disc (which, it’s worth mentioning, aren’t actually used by the game) don’t seem to be configured correctly.

As an example, let’s look at boy_0.arc.

While this file contains a valid act and gpl, it has 3 seperate texture (tpl) files for the body (b0), eyes (f0_e), and mouth (f0_m).

This is a problem because most gpl files are coded to load one tpl file. In this case, we can open boy_0.gpl in a hex editor and see that it’s supposed to load all of it’s textures from a nonexistent Boy_0.tpl file.

As such, attempting to load the boy_0 model using the above method I tried for bass, will not work. The program will simply give an error “Could not find CarDemo/Boy_0.tpl” and freeze/crash.

Attempting to rename any of the other texture files (e.g. renaming boy_0_b0.tpl to Boy_0.tpl) also doesn’t work, it just causes a crash. This is likely because the elusive Boy_0.tpl file would include all body, eye, and mouth textures in one single tpl file.

More Research Required

I plan on doing more testing with the Service Disc and the CarDemoN program.

There’s also other demos, disc:/ntd/zebraA.dol and disc:/ntd/zebraS.dol, that could be useful for viewing models/animations.

There’s also a program disc:/ntd/preview.dol that might be useful for previewing models.

Hopefully I’ll be able to come up with something over the next few weeks.

Ghidra, a potentially useful reverse-engineering tool

In the past, I’ve tried to decompile the game’s code using RetDec.

While I was successful in translating the games binary into some pseudo-code, I couldn’t really do anything with it.

Recently, the NSA declassified and released a powerful reverse-engineering tool called Ghidra.

In addition to that, someone created a language definition for Ghidra, containing specific instructions for the GameCube’s Gekko processor.

How to Import AWL code into Ghidra

Extracting the Executable From the Game

To analyze AWL (or AnWL) code with Ghidra, you’ll need to extract the game’s main executable.

This can be named Start.dol, boot.dol, or main.dol, depending on your tool of choice.

The executable can be extracted using Dolphin by right-clicking on your ISO and selecting “Properties”

Then, in the Filesystem tab, right-click the Disc and select “Extract System Data”

You’ll find the extracted executable named main.dol in your chosen folder.

Converting the Executable to a Better Format

Gamecube executables are typically in a DOL format. While this can, in theory be analyzed, it’s much easier for Ghidra (and other tools) to analyze an ELF-format file.

To do this, we can use a tool aptly called DolTool.

Simply copy your main.dol file into the DolTool directory and open up a command prompt in the folder. Then run the following.

DolTool.exe -e main.dol

Importing your ELF into Ghidra

Create a new Ghidra project, then select File -> Import, and select your new main.elf file.

In the following screen, select the “Executable and Linking Format” format and “PowerPC:BE:32:Gekko_Broadway:default” language

Analyzing main.elf

Finally, right-click your newly imported main.elf file and select “Open in Default Tool”

The file should then open up in CodeBrowser and prompt you to analyze it.

From here, you’re free to use the program to analyze the code and it’s functions.

Playing around with Ghidra, I located this bit of code that seems to load the mainchapter CLZ files

I don’t have much experience with reverse engineering, so you’re on your own from this point forward.