New obsession

Ever since I acquired my Katana in 2014, I’ve always wanted to try doing some kind of Online game. The ultimate path to the end was hazy at first, especially when it came to available SDKs and whatnot. A big issue with the Dreamcast is that there’s no good way of updating the game executable. Not only updating it, but doing so with at least data integrity in mind. Also, now I have the limitation of what was available at the time and that isn’t great. The other thing is that this is sort of like closing the gate after the horse has bolted. Attempting to add something to the Dreamcast that it really wasn’t designed for (unlike the Original Xbox) is a challenge.

One of the first steps on this journey has been researching how to sign executables and figure out how to apply that to the way the Dreamcast wants to do things. I’ve not settled on a final format, though I’m leaning toward adding the signature of the whole executable at the beginning and either using ELF to further sign each segment of the binary or just do with the stripped version. This will require a bootstrapper of sorts, i.e. 1ST_READ.BIN, to read the correct file (I haven’t decided on a name, something like ENTRY, MAIN, GAME, or DEFAULT) which will be located first by querying for a mass storage expansion device, then falling back to the GD-ROM. Loading the signature into memory, loading the image into memory, compare the signature with the key stored on the Dreamcast.

I forgot to mention; I’ve been a little fucked over with the R11 SDK. The interface to the Flash memory is an older version (1.02) and the most up-to-date version’s (1.04) headers just aren’t on any SDK. I’ve looked at R9 and R10.1 as well. The release notes for R11 mention that the Flash memory interface has been added, which is peculiar considering the date is November 27 1998. Anyway, there are only two interfaces available: fmMngRead and fmMngExecServer. This is only two of the six or so available functions. After reverse-engineering the other functions, I’ve added their definitions into Shambler and everything seems to be working as expected. I’m very, very wary of using the Flash, for obvious reasons, mostly that I have no idea how to guarantee that enough contiguous blocks are available. For kicks, I tried out PSO on my kit and it wants to write to block 8 on partition 2. Before that was another chunk at block 5. These may be completely fixed and I’m shit out of luck to get enough contiguous blocks. The Internet configuration settings do seem to be fixed as well. There are 254 blocks in total to work with. I’m unsure exactly which method I’ll be using for the key. I’m sure it won’t be more than a few hundred bytes. Anyway, back to my idea for the bootstrapping process.

After checking for a key in Flash, it will either be added or used. The big issue is that the key can’t just live on the Dreamcast, it has to get there somehow. Anyone could modify the bootstrapper to add or replace the key with something malicious because there just isn’t any good way of doing this that’s completely bulletproof. At the very least, this offers some level of data integrity checking. When the game’s executable is verified, the data would have already been copied to the correct offset in memory and can just be jumped to. If it fails when loading from external storage, it will attempt to use the one on the GD-ROM, again going through the same process. Otherwise, it will bail and inform the player that something went wrong.

That’s the idea, anyway. A sort of poor-man’s auto updater integrity solution.

Now that I’ve noted that down, back to doing something about that darn “teaser” that I keep, well, teasing.

I’m considering just offering up what I have on a weekly basis, going forward, if there’s been any (and I mean any) progress.