Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

Investigating Steam for Linux

February 28th, 2013 by Multimedia Mike

Valve recently released the final, public version of their Steam client for Linux, and the Linux world rejoiced. At least, it probably did. The announcement was 2 weeks ago on Valentine’s Day and I had other things on my mind, so I missed any fanfare. When framed in this manner, the announcement timing becomes suspect– it’s as though Linux enthusiasts would have plenty of time that day or something.


Valve Steam logo

Taming the Frontier
Speculation about a Linux Steam client had been kicking around for nearly as long as Steam has existed. However, sometime last year, the rumors became more substantive.

I naturally wondered how to port something like Steam to Linux. I have some experience with trying to make a necessarily binary-only program that runs on Linux. I’m fairly well-versed in the assorted technical challenges that one might face when attempting such a feat. Because of this, whenever I hear rumors that a company might be entertaining the notion of porting a major piece of proprietary software to Linux, my instinctive reflex is, “What?! Why, you fools?! Save yourselves!”

At least, that’s how it used to be. The proposal of developing a proprietary binary for Linux has been rendered considerably less insane by a few developments, for example:

  1. The rise of Ubuntu Linux as a quasi de facto standard for desktop Linux computing
  2. The increasing homogeneity in personal desktop computing technology

What I would like to know is how the Steam client runs on Linux. Does it rely on any libraries being present on the system? Or does it bring its own? The latter is a trick that proprietary programs can use– transport all of the shared libraries that the main program binary depends upon, install them someplace out of the way on the filesystem, probably in /opt, and then make the main program a shell script which sets a preload path to rely on the known quantity libraries instead of the copies already on the system.

Downloading and Installing the Client
For this exercise, I installed x86_64 desktop Ubuntu 12.04 Linux on a l33t gaming rig that was totally top of the line about 5 years ago, and that someone didn’t want anymore and handed down to me recently. So it should be ideal for this project.

At first, I was blown away– the Linux client is in a .deb package that is less than 2 MB large. I unpacked the steam.deb file and found a bunch of support libraries — mostly X11 and standard C/C++ runtimes. Just as I suspected. Still, I can’t believe how small the thing is. However, my amazement quickly abated when I actually ran Steam and saw this:


Steam Linux Client -- initial update

So it turns out steam.db is just the installer program which immediately proceeds to download an additional 160+ MB of data. So there’s actually a lot more information to possibly sift through.
Read the rest of this entry »

Posted in Game Hacking | 4 Comments »

Game Music Appreciation

July 15th, 2012 by Multimedia Mike

A little over a year ago, I was prototyping a method to leverage Google Chrome’s Native Client technology in order to play old chiptunes (video game music) directly in a web browser. The last time I posted on the matter, I said that I might have something ready for public consumption by the time Google Chrome 21 rolled around. I thought I was being facetious but I wasn’t too far off. Chrome 20 is the current release version as I write this.

Anyway, I did it: I created a chiptune music player in Native Client by leveraging existing C/C++ libraries such as Game Music Emu, Audio Overload SDK, and Vio2sf. Then I packaged up the player into into a Google Chrome extension and published it on the Chrome Web Store. Then I made a website cataloging as many chiptunes as I could find for 7 different systems:

http://gamemusic.multimedia.cx/

Check it out if you have any affinity for old game music or you want to hear how music was made using a limited range of bleeps and bloops. Thus far, the site catalogs NES, SNES, Game Boy, Nintendo DS, Genesis, Saturn, and Dreamcast songs. I’m hoping to add support and catalogs for many more systems, though, eventually bringing support in line with the Chipamp plugin for Winamp.

Posted in Game Hacking | 2 Comments »

The 11th Hour RoQ Variation

April 11th, 2012 by Multimedia Mike

I have been looking at the RoQ file format almost as long as I have been doing practical multimedia hacking. However, I have never figured out how the RoQ format works on The 11th Hour, which was the game for which the RoQ format was initially developed. When I procured the game years ago, I remember finding what appeared to be RoQ files and shoving them through the open source decoders but not getting the right images out.

I decided to dust off that old copy of The 11th Hour and have another go at it.



Baseline
The game consists of 4 CD-ROMs. Each disc has a media/ directory that has a series of files bearing the extension .gjd, likely the initials of one Graeme J. Devine. These are resource files which are merely headerless concatenations of other files. Thus, at first glance, one file might appear to be a single RoQ file. So that’s the source of some of the difficulty: Sending an apparent RoQ .gjd file through a RoQ player will often cause the program to complain when it encounters the header of another RoQ file.

I have uploaded some samples to the usual place.

However, even the frames that a player can decode (before encountering a file boundary within the resource file) look wrong.

Investigating Codebooks Using dreamroq
I wrote dreamroq last year– an independent RoQ playback library targeted towards embedded systems. I aimed it at a gjd file and quickly hit a codebook error.

RoQ is a vector quantizer video codec that maintains a codebook of 256 2×2 pixel vectors. In the Quake III and later RoQ files, these are transported using a YUV 4:2:0 colorspace– 4 Y samples, a U sample, and a V sample to represent 4 pixels. This totals 6 bytes per vector. A RoQ codebook chunk contains a field that indicates the number of 2×2 vectors as well as the number of 4×4 vectors. The latter vectors are each comprised of 4 2×2 vectors.

Thus, the total size of a codebook chunk ought to be (# of 2×2 vectors) * 6 + (# of 4×4 vectors) * 4.

However, this is not the case with The 11th Hour RoQ files.

Longer Codebooks And Mystery Colorspace
Juggling the numbers for a few of the codebook chunks, I empirically determined that the 2×2 vectors are represented by 10 bytes instead of 6. Now I need to determine what exactly these 10 bytes represent.

I should note that I suspect that everything else about these files lines up with successive generations of the format. For example if a file has 640×320 resolution, that amounts to 40×20 macroblocks. dreamroq iterates through 40×20 8×8 blocks and precisely exhausts the VQ bitstream. So that all looks valid. I’m just puzzled on the codebook format.

Here is an example codebook dump:
Read the rest of this entry »

Posted in Game Hacking | 5 Comments »

Pushing Projects to Github

February 16th, 2012 by Multimedia Mike

I finally got around to importing some old projects into my Github account. I guess it’s good to have a backup out there in the cloud.

GhettoRSS
https://github.com/multimediamike/GhettoRSS
I describe this as a true offline RSS reader. Technically, it’s arguably not a true offline RSS reader. Rather, it does what most people actually want an offline RSS reader to do.

I wrote this about 2 years ago when I had a long daily train ride with a disconnected netbook. I quickly learned that I couldn’t count on offline RSS readers simply because most RSS feeds to not contain much meat. Thus, I created a program that follows URLs in RSS feeds, downloads web pages and supporting images and CSS files, and caches them in an offline database which can be read via a local web browser.

I wrote more information about this little project 2 years ago (here is part 1 and here is part 2). I fixed a few bugs in preparation for posting it but I probably won’t work on this anymore since I don’t have any use for it (the commute is long gone, but I didn’t even use it when I was commuting because I decided I just didn’t care enough to read the feeds on the train).

xbfuse
https://github.com/multimediamike/xbfuse
This is a FUSE module for mounting Xbox/360 optical disc filesystems. Here is when I first discussed it. The tool has had its own little homepage for a long time. This tool has seen some development, as I learned from Googling for “xbfuse”. Regrettably, no one who has modified the tool has ever contacted me about it (at least, not that I can recall). This is unfortunate because the patches I have seen floating around which fix my xbfuse for various installations usually boil down replacing many occurrences of an include path in the autotool-generated build system. There is probably a simpler, cleaner fix.

gcfuse
https://github.com/multimediamike/gcfuse
Written prior to xbfuse, this is a FUSE module for mounting GameCube optical disc filesystems. I first discussed this here and here. This tool has not seen too much direct development although someone eventually used it as the basis for WiiFuse which, as you can predict, mounts optical disc filesystems from Nintendo Wii games.

Posted in Game Hacking, Python | Comments Off

Origin Crusader Media

February 13th, 2012 by Multimedia Mike

A gleaming copy of the old Origin game Crusader: No Remorse showed up today:



Immediately, I delved in expecting to find Xan-encoded AVI files that would play perfectly using FFmpeg/Libav. Instead, I found a directory labeled flics/ that indeed has a lot of AVI files, but not in Xan. The programs attempt to interpret them as raw RGB. The strangest thing is the first frame often looks correct, if upside down:



The first file I peered inside had the video FourCC ‘RRV1′. Searching for this led me to this discussion forum where people have already been hacking on this very format (Origin games invariably get a heap of lasting love). The forum participants have observed that 3 codecs are in play in this flics/ directory, including ‘RRV1′, ‘RRV2′, and ‘JYV1′, which apparently correspond to the initials of certain developers. The reason that the programs identify the files as raw RGB is because the FourCCs don’t appear everywhere that they’re supposed to. Additionally, there are several trailers for other Origin/EA games stored in Cinepak format elsewhere on the disc.

It seems that I’m the person who added this title to the Xan wiki page, obviously with no first-hand evidence to back it up. Meanwhile, the forum participants speculate that the files are descended from the old Autodesk FLIC format (which would explain why they live in a directory called flics/). Corroborating strings extracted from the CRUSADER.EXE file include “FlicWait”, “FlicPlayer”, “Flic %s not found.”, “flicpath”, and “FLICPLAY.C”.

The disc also features a sound/ directory which contains AMF files. Suxen Drol already documented these on the wiki as Asylum Media Format files. The disc contains an ASYLUM.DLL file as well as a utility called MOD2AMF.EXE. The latter works beautifully on a random MOD file I had laying around. The AMF file is a bit larger.

Samples for all 3 FourCCs can be found here, while the AMF files and associated utilities are here.

Posted in Game Hacking | 4 Comments »

Samples RSS And Flashback Samples

December 21st, 2011 by Multimedia Mike

I made good on my claim that I would create an RSS feed for the samples repository.

Here is the link to the samples RSS feed [ http://samples.mplayerhq.hu/samples-rss.xml ]. Also, here is the Python source code I threw together for the task.

I just want to check: I’m not the only person who still relies on RSS these days, right? The tech press has been cheerfully proclaiming its demise for some time now. But then, they have been proclaiming the same for Adobe Flash as well.

I’m no expert in RSS. If you have any suggestions for how to improve the features presented in the feed, please let me know. And, of course, keep the samples coming. This script should help provide more visibility for a broader audience.

Mario and Flashback Samples
Thanks to LuigiBlood who sent in some samples that allowed me to test out my new script for automatically syncing the repositories and updating the samples RSS feed. First, there are CPC multimedia files from the Japanese 3DO port of Flashback: The Quest for Identity. Then, there is an Interplay MVE file on the CD version of Mario Teaches Typing in which the video doesn’t decode correctly.

LuigiBlood also sent in another file from the latter game. It’s big and has the extension .AV. It could be a multimedia file as it appears to have a palette and PCM audio inside. But there’s no header and I’m a bit unsure about how to catalog it.

Posted in Game Hacking, Python | 14 Comments »

Space Adventure CD-ROM

September 30th, 2011 by Multimedia Mike

I acquired a CD-ROM entitled Space Adventure by Knowledge Adventure (I like these people; they make decent, entertaining educational games). The physical media displays a copyright date of 1993, very early in the multimedia era.



This 1993 CD-ROM makes proud use of multimedia files. What kind? There’s a movies/ directory with 17 .mov files. It would be way too simple if these were QuickTime files, though. These represent a custom format, and video-only since a separate sounds/ directory contains .snd files with filenames corresponding to the .mov files. The .snd files are actually Creative Voice (a.k.a. VOC) files. As for this MOV format, wiki page and samples.



I was also surprised to find the binary ultrasnd.exe file among the drivers on the disc. The Gravis UltraSound was released in 1992. The sound setup utility does not have an option for the GUS, however. No matter since DOSBox has great SB/Pro/16 emulation.

I’m also a bit puzzled about why the DOSBox screenshots are 720 x 480 (posted here are various cropping and resizings).

Posted in Game Hacking | 6 Comments »

Metal Gear Solid VP3 Easter Egg

August 3rd, 2011 by Multimedia Mike

Metal Gear Solid: The Twin Snakes for the Nintendo GameCube is very heavy on the cutscenes. Most of them are animated in real-time but there are a bunch of clips — normally of a more photo-realistic nature — that the developers needed to compress using a conventional video codec. What did they decide to use for this task? On2 VP3 (forerunner of Theora) in a custom transport format. This is only the second game I have seen in the wild that uses pure On2 VP3 (first was a horse game). Reimar and I sorted out most of the details sometime ago. I sat down today and wrote a FFmpeg / Libav demuxer for the format, mostly to prove to myself that I still could.

Things went pretty smoothly. We suspected that there was an integer field that indicated the frame rate, but 18 fps is a bit strange. I kept fixating on a header field that read 0x41F00000. Where have I seen that number before? Oh, of course — it’s the number 30.0 expressed as an IEEE 32-bit float. The 4XM format pulled the same trick.

Hexadecimal Easter Egg
I know I finished the game years ago but I really can’t recall any of the clips present in the samples directory. The file mgs1-60.vp3 contains a computer screen granting the player access and illustrates this with a hexdump. It looks something like this:



Funny, there are only 22 bytes on a line when there should be 32 according to the offsets. But, leave it to me to try to figure out what the file type is, regardless. I squinted and copied the first 22 bytes into a file:

 1F 8B 08 00   85 E2 17 38   00 03 EC 3A   0D 78 54 D5
 38 00 03 EC   3A 0D 

And the answer to the big question:

$ file mgsfile
mgsfile: gzip compressed data, from Unix, last modified: Wed Oct 27 22:43:33 1999

A gzip’d file from 1999. I don’t know why I find this stuff so interesting, but I do. I guess it’s no more and less strange than writing playback systems like this.

Posted in Game Hacking | 16 Comments »

Multimedia Exploration Journal: The Past Doesn’t Die

July 11th, 2011 by Multimedia Mike

New haul of games, new (old) multimedia formats.

Lords of Midnight
Check out the box copy scan for Lords of Midnight in MobyGames. In particular, I’d like to call your attention to this little blurb:



Ahem, “Journey through an immense world — the equivalent of 8 CD-ROMs.” Yet, when I procured the game, it only came on a single CD-ROM. It’s definitely a CD-ROM (says so on the disc) and, coming from 1995, certainly predates the earliest DVD-ROMs (which can easily store 8 CD-ROMs on a disc). Thus, I wanted to jump in a see if they were using some phenomenal compression in order to squeeze so much info into 600 or so megabytes.

I was surprised to see the contents of the disc clocking in at just under 40 megabytes. An intro movie and an outro movie account for 75% of that. Format? None other than that curious ASCII anomaly, ARMovie/RPL with Escape 122 codec data.

Cyclemania



Cyclemania is one of those FMV backdrop action games, but with a motorcycle theme. I had a good feeling I would find some odd multimedia artifacts here and the game didn’t disappoint. The videos are apparently handled using 3-4 discrete files per animation. I’ve documented my cursory guesses and linked some samples at the new MultimediaWiki page.

Interplay ACMP
This is unrelated to this particular acquistion, but I was contacted today about audio files harvested from the 1993 DOS game Star Trek: Judgment Rites. The files begin with the ASCII signature “Interplay ACMP Data”. This reminds me of Interplay MVE files which begin with the similar string “Interplay MVE File”. My theory is that these files use the ACOMP compression format, though I’m still trying to make it fit.

Wiki and samples are available as usual if you’d like to add your own research.

Posted in Game Hacking | 1 Comment »

SNES Hardware Compression

June 16th, 2011 by Multimedia Mike

I was browsing the source code for some Super Nintendo Entertainment System (SNES) emulators recently. I learned some interesting things about compression hardware. I had previously uncovered one compression algorithm used in an SNES title but that was implemented in software.

SNES game cartridges — being all hardware — were at liberty to expand the hardware capabilities of the base system by adding new processors. The most well-known of these processors was the Super FX which allows for basic polygon graphical rendering, powering such games as Star Fox. It was by no means the only such add-on processor, though. Here is a Wikipedia page of all the enhancement chips used in assorted SNES games. A number of them mention compression and so I delved into the emulators to find the details:

  • The Super FX is listed in Wikipedia vaguely as being able to decompress graphics. I see no reference to decompression in emulator source code.
  • DSP-3 emulation source code makes reference to LZ-type compression as well as tree/symbol decoding. I’m not sure if the latter is a component of the former. Wikipedia lists the chip as supporting “Shannon-Fano bitstream decompression.”
  • Similar to Super FX, the SA-1 chip is listed in Wikipedia as having some compression capabilities. Again, either that’s not true or none of the games that use the chip (notably Super Mario RPG) make use of the feature.
  • The S-DD1 chip uses arithmetic and Golomb encoding for compressing graphics. Wikipedia refers to this as the ABS Lossless Entropy Algorithm. Googling for further details on that algorithm name yields no results, but I suspect it’s unrelated to anti-lock brakes. The algorithm is alleged to allow Star Ocean to smash 13 MB of graphics into a 4 MB cartridge ROM (largest size of an SNES cartridge).
  • The SPC7110 can decompress data using a combination of arithmetic coding and Z-curve/Morton curve reordering.

No, I don’t plan to implement codecs for these schemes. But it’s always comforting to know that I could.

Not directly a compression scheme, but still a curious item is the MSU1 concept put forth by the bsnes emulator. This is a hypothetical coprocessor implemented by bsnes that gives an emulated cartridge access to a 4 GB address space. What to do with all this space? Allow for the playback of uncompressed PCM audio as well as uncompressed video at 240x144x256 colors @ 30 fps. According to the docs and the source code, the latter feature doesn’t appear to be implemented, though; only the raw PCM playback.

Posted in Game Hacking | 8 Comments »

« Previous Entries