I’ve been suffering through a wave of interactive movie schlock for my Gaming Pathology project. This has led me to hypothesize about what I can do to help share these wretched I-movie experiences with a broader audience and even preserve this misery for future generations to revile. To that end, I have brainstormed about the Dynamic Uninteresting Movie-Based Adventure System Simulator (thanks to Cyril Z. for helping me with the expository project name).

Loosely, an I-movie is a “game” that relies heavily on pre-rendered full motion video (FMV) sequences. The sequences can be used to show transitions from one location to another or — more often than not — exhibit a marginal actor disgracing his chosen craft in order to advance the sheer confusion that passes for a storyline. Many of these so-called games also feature one or more puzzles so as not to rely entirely on one type of gameplay.

After playing through a number of these I-movie titles, I can’t help but notice certain programmatic similarities. For example, games like D and Of Light And Darkness feign immersive 3D environments with a combination of FMV files. Start at point A. Define a series of hotspots for the current scene that map to other FMV files. When the player clicks in one of those hotspots, play the next FMV file. There; that’s 90% of the game engine right there.

Internally, the games probably have a little of what might be termed a virtual machine in order to track the game’s state. At least, I postulate that it could be forced into some kind of virtual machine structure. This is used for tracking how far the player has progressed into the game, which hoops he has jumped through, and, by extension, what special things need to happen on certain screens. this would also pertain to various puzzles which are typically comprised of series of FMV files.

So here’s the pitch: A portable virtual machine in the spirit of ScummVM that knows how to interpret the data files for a variety of these I-movies and force them into a common model. This would probably entail a graph data structure describing a map and which FMV files get played when the player chooses to transition from point A to point B. Further, there would be some list of game goals to progress through. Most of these I-movies couldn’t possibly be much more involved than that. From my understanding, most of the FMV formats that these games use are already well supported by portable, open source software.

It’s just crazy enough to work. And to what end? That should be obvious– to continue humiliating the people responsible for these tarnishes on the good name of computer gaming.

“Unnamed RE Project” is the impromptu name I gave to a program that I hastily wanted to start but couldn’t be bothered to come up with even a quasi-clever name. Moreover, I actually got it to do something. I can’t believe I actually made a go of this, perhaps one of the most useless reverse engineering exercises.

Aside: Does this still qualify for my “outlandish brainstorms” blog category if I actually made it work?

The basic idea is one that a lot of reverse engineers surely kick around at some point: A set of CPU registers can be abstracted as a set of global C program variables and individual assembly language instructions map quite neatly onto C program statements. Thus, what about an automatic conversion utility that can take an ASM disassembly and convert it into a C program that can be portably compiled? Not optimal, but it might be a start for other RE projects.

Traditionally, I objected to this approach on the basis of its inherent impurity– one of my objectives in this RE journey is to understand the algorithms being recovered. Technically, while it sounded like a simple enough concept, when one actually sits down to think about, all kinds of problems crop up. One of the most immediate is how case statements (jumps using dynamic tables) would be handled.

Putting aside all uncertainty, I decided to go for it and see what could happen. Believe it or not, I met with some success while also discovering a number of problems I hadn’t yet realized (for example, the dream of portability goes right out the window). I hope to write up some more about this shortly. But for tonight, I will just show the results of the first experiment.

Read the rest of this entry »

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.

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.

I really like FUSE, the filesystem in userspace that facilitated the creation of gcfuse. I think the killer app for FUSE is sshfs. It’s a minor miracle that if you have an SSH server running on a machine you can use sshfs to mount a filesystem from another machine. Authentication, encryption, all taken care of. None of that NFS or Samba configuration hassle.

I started wondering what else I might be able to use FUSE for. There is the small issue of Sega Dreamcast disc images. These games contain a lot of multimedia encoded with Sofdec’s middleware tools. For the most part, these discs use an ISO-9660-like filesystem that’s just a little different and doesn’t operate with Linux’s ISO-9660 module. Perhaps a FUSE/ISO-9660 module that can also handle the modified Dreamcast variant? Actually, I see that the big FUSE app directory lists an app appropriately named fuseiso which can load an ISO-9660 filesystem. It might be worth a look.

Thinking bigger, what about a FUSE module that mounts a DVD and presents it in some interesting manner? For starters, it will transparently decrypt the data. Then, present the contents of the DVD as a series of chapters or tracks or menu options. Since a DVD is not necessarily a strict hierarchy, perhaps organize the different viewing options in different directories. Or a /proc-like special filesystem that allows tinkering with the audio and subtitle options. It’s late and I’m just tossing out ideas here. Feel free to jump in.

I was perusing my old Nintendo Power issues today, as I am wont to do for no good reason, and I stumbled upon a forgotten bonus that the magazine shipped to its subscribers once upon a time– Top Secret Passwords:

Click for a larger image, and to guess which game is covered by the level 8 password on the sticky note

Now I’m playing with power. They put a tremendous amount of work into that cover. Passports for not only the Principality of NES but also the Republic of SNES. I guess in the early 1990s, nothing said “top secret” quite like a portable phone. Luckily, the book features passwords for Solar Jetman, the present object of my password infatuation. I wonder if the official password validator accepts the secret password comprised of all ‘Q’s, or if that’s handled by a special case.

Not only is Solar Jetman covered in the book but when I opened the book a carefully folded piece of paper slid out. It contained a number of very neatly written passwords, including ones for every world in Solar Jetman! It doesn’t look like my handwriting, plus the paper includes passwords for games that I never would have been caught dead playing. What a mystery. It’s almost like someone meant for me to find these clues and take up the cause of researching these ancient Nintendo password systems.

The password book contains passwords for a number of games where the only information carried in the password is what level the player was on. For a number of such games, I did a quick string check through the respective ROM data for the passwords. It looks like no coders bothered to use straight string comparison techniques for password validation.

One can only guess what sort of international espionage thrillers influenced the book’s artists, but their conceptualization of incognito (and airplane markings) involved a lot of pink:

Click for larger image of Codename: Pink Gamer

I spent the vast majority of my junior high free time in front of a scratchy television connected to a Nintendo Entertainment System (NES) console. (Try not to act too surprised.) Many of the more involved Nintendo games either had battery-backed RAM on the cartridge PCB for saving games or employed a password system. The game would issue a password at various junctures in the game that you were expected to copy down accurately so that you could resume your game at a later time. Password lengths were commensurate with the complexity of the game and the amount of information required to represent a game’s state. For example, some games obviously had a table of plaintext 4- or 5-character passwords since the only information being saved was which of the game’s 8 levels the player has just passed. On the other end of the spectrum, the most complex password system I ever encountered was for Wall Street Kid, the groundbreaking stock market sim for the NES. It was a variable length password (at least 50 characters was nominal, if memory serves) with just about every letter of the English alphabet, upper and lower case, numbers, and various other symbols. I don’t think I ever successfully copied down a password for that game.

Wall Street Kid

Read the rest of this entry »

Pursuant to Alex’s challenge to write a Unix player for Trixter’s 8088 Corruption data file, combined with an interest in re-learning the Simple DirectMedia Layer (SDL) API, I wrote a basic program that takes said data file, a font file, and the hardwired colors in the CGA card and renders the video using SDL. I don’t think the font vectors I scavenged are 100% the same as the ones in Trixter’s IBM model 5150 PC:

In particular, I’m not sure about all of those box characters. I think the box is supposed to be one flat color. Anyway, here is another shot, only from the “Tron light cycles” section of video:

Followed up in SDL Corruption Corrected.

After sorting out Trixter’s 8088 Corruption details sometime ago I started to wonder about FMV on other relatively low-power systems. Let’s consider the Super Nintendo Entertainment System (SNES).

The SNES came out quite some time after the original IBM PC (10 years?). Still, the original IBM PC targeted in Trixter’s experiment had several advantages such as more capacity (10 megabytes of HD space), a marginally more powerful CPU (Intel 8088 @ 4.77 MHz), and a pre-defined vector codebook for the FMV hack.

Let’s start with a modest goal: 1 full minute (60 seconds) of full motion video and audio on the regulation Super Nintendo Entertainment System hardware.

Read the rest of this entry »

Exploiting capabilities/limitations of available video hardware is nothing new in terms of multimedia programming. The old IBM VGA hardware had a 320×200 resolution mode that could display 256 unique colors. For years, that drove many graphic-heavy applications (notably games but also certain video applications such as FLIC files originally generated by Autodesk software). Back when I was hacking on the Sega Dreamcast I started to brainstorm about a vector quantizer video codec that could take advantage of the PowerVR 3D graphics hardware present in the console.

Read the rest of this entry »

I move swiftly from project to project and I know some readers are hoping that I succinctly forget about this multimedia programming language idea. Just a few more thoughts:

Matthieu Castet tipped me off that gcc 4 actually offers vector data type extensions. The concept is to declare and use vector data types in such a way that the compiler will understand how to transform them into SIMD instructions (MMX, SSE2, Altivec, et al). Please forgive my skepticism regarding how well this could possibly work. I do not begrudge the gcc developers for their roles; I know it’s a tough duty and I appreciate that gcc works across so many different CPU architectures. However, one area of gcc that seems to break down with inordinate regularity is optimization along with C/ASM code intermingling.

One item that I did not make clear in my first post about the language is driving motivation. The idea is to take something that resembles an ISO-style spec and compile it directly. Have you ever looked at a formal ISO spec? Probably not an official one, but chances are that if you have been working on multimedia tech for any period of time you have at least seen ISO draft documents floating around on the internet. Generally, they are impenetrable but also highly programmatic. I think it would be useful to compile the specs directly.

Maybe I am thinking of some literate programming variation.