Author Archives: Multimedia Mike

gcfuse, With Executable Support

I upgraded my gcfuse utility tonight. The main change was to expose the primary game executable file when browsing a GameCube filesystem. The primary executable is stored as an implicit part of the filesystem, separate from the directory structure. Being able to easily read this file is a useful feature if, for example, someone wishes to get at these executables for the purpose of disassembly.

For example, when mounting the first disc image of one of my few GC games that I have actually completed, Metal Gear Solid:

$ ls -al mount/
total 1
dr-xr-xr-x 4 melanson users         0 Jul 15  2005 .
drwxr-xr-x 7 melanson users       760 Aug 26 21:48 ..
-r--r--r-- 1 melanson users        95 Jul 15  2005 .metadata
dr-xr-xr-x 4 melanson users         0 Jul 15  2005 audio
-r--r--r-- 1 melanson users 426387456 Jul 15  2005 demo.dat
-r--r--r-- 1 melanson users   1988128 Jul 15  2005 metal-gear-solid-the-twin-snakes-exe.dol
-r--r--r-- 1 melanson users      6496 Jul 15  2005 opening.bnr
dr-xr-xr-x 3 melanson users         0 Jul 15  2005 shared
-r--r--r-- 1 melanson users 198715392 Jul 15  2005 stage.dat

The executable file is metal-gear-solid-the-twin-snakes-exe.dol. The filename is a little long, which can happen since it is derived from the game title in the disc metadata, which can be nearly 1000 characters long. The GC executable format is known as DOL, probably short for Dolphin which was the codename of the GameCube during development.

I recognize that I’m likely the only person on the planet who cares about this utility but, hey, it’s my blog and what are blogs for if not to tell the world about the tedious minutiae of an individual’s life?

Related post:

CD Detection Experiment

Some years ago, I wrote a program named the CD Detection Experiment to toy around with compact discs. I reference this tool often in my Multimedia Exploration Journal. The end goal was a tool that could analyze a variety of different CD types, including mode 2 discs, Philips CD-I discs, and 3DO discs. All it does is open a raw CD device under Unix, check the first few sectors, and decide what kind of CD is in the drive. I’m trying to remember if this tool preceded my CD-related work for xine or if I used code from my xine work in this program. There is code for Solaris and FreeBSD reading, so I am guessing that I based this on the xine work.


CDCDCD

Anyway, if you care, here is the code. Here is some sample output, from that Deathtrap Dungeon game discussed in this journal entry, the one with a weird mixed mode:

$ ./cdexp /dev/cdrom
CD Detection Experiment
toc:
  first track = 1
   last track = 18

toc entries:
leadout track: MSF: 76:16:18, first frame = 343218
track  1,  data, MSF: 00:02:00, first frame = 150
 mode 1 data
 iso9660 fs signature found
 system id =
 volume id = Deathtrap
track  2, audio, MSF: 28:09:14, first frame = 126689
track  3, audio, MSF: 30:37:58, first frame = 137833
track  4, audio, MSF: 32:37:28, first frame = 146803
track  5, audio, MSF: 35:32:30, first frame = 159930
track  6, audio, MSF: 39:57:58, first frame = 179833
track  7, audio, MSF: 43:07:24, first frame = 194049
track  8, audio, MSF: 45:45:35, first frame = 205910
track  9, audio, MSF: 49:33:19, first frame = 222994
track 10, audio, MSF: 52:38:22, first frame = 236872
track 11, audio, MSF: 55:17:04, first frame = 248779
track 12, audio, MSF: 58:13:66, first frame = 262041
track 13, audio, MSF: 60:28:28, first frame = 272128
track 14, audio, MSF: 62:43:43, first frame = 282268
track 15, audio, MSF: 64:59:33, first frame = 292458
track 16, audio, MSF: 67:14:00, first frame = 302550
track 17, audio, MSF: 75:36:00, first frame = 340200
track 18,  data, MSF: 76:00:00, first frame = 342000
 mode 1 data
 iso9660 fs signature found
 system id =
 volume id = Deathtrap

Mounting An Executable

I was studying the Executable & Linking Format (ELF) recently. I realized how hierarchically it is organized. Nowadays, whenever I think of something hierarchical, for some reason, I think of cramming it into a filesystem structure via FUSE. Imagine mounting an executable file as a filesystem. One directory could have a list of exported function names. When reading those files, it would automatically disassemble that section of the file.


Executable

I’m working off of the ‘readelf -a’ command here. There would be a directory at the top level called sections/ and would contain 

  .interp/
  .hash/
  .dynsym/
  .dynstr/

And so on. It might be a little tricky because those names have dots in front of them. Another directory can list shared libraries and have symbolic links to the correct libraries. Another directory will list the exported, public symbols. Opening these files would disassemble the functions for display in whatever text editor you want. Of course, not all of the interesting stuff is found at the public entry points, so it will be necessary to employ heuristics to locate other, private function entry points.

For bonus points, make the filesystem writable. This will allow annotations in the disassembled source. This will probably require that a “work” copy of the binary to be stored in the user’s home directory.