Yearly Archives: 2006

Licensed Schlock

While browsing at a Salvation Army store this past weekend I found a bin of old CD-ROMs. Naturally, I just had to get a few. Actually, I probably would have taken most of the bin if the merchandise was less than a static $2 per disc. But there was at least one disc I just couldn’t pass up– a Taco Bell-themed computer game. Tek Kids something or other, and disc 2 of 4 to boot. It likely came with a children’s meal for little or no cost above and beyond the cost of the meal. This means I probably paid more for it than the original customer did. Still, I look forward to seeing what the thing is all about.

I also recently learned that Burger King is running a promotional Xbox game tie-in where customers can purchase one of 3 BK-themed Xbox/Xbox 360 games for a nominal price in addition to their meal. Collect them all!

This all reminds me that I have a pile of licensed schlock game titles to review for multimedia purposes, many procured from a variety of garage sales (and many which still need permanent homes is the MobyGames database). You-have-to-see-it-to-believe-it titles include:

  • Tek Kids Flash Ops– Mission: Polar Challenge (the aforementioned Taco Bell game)
  • Snowday: The Gap Kids Quest
  • Little Caesar’s Fractions Pizza
  • Kellogg’s Pop-Tarts Presents: Rescue The Rusties
  • 13 Days of Halloween: Rhythm And Boos (breakfast cereal tie-in)
  • Cap’n Crunch’s Crunchling Adventure


Game backlog
click for a closer look

And this further reminds me what kind of a backlog I’m still looking at for my Multimedia Exploration Journal. Some people observe that I’m the only person they know that thinks it’s a chore to work through this many games; the only person who sighs and talks about how many games are yet to “be processed”.

It’s the path I’ve chosen.

PlayStation 3 HackWatch

Now that the Sony PlayStation 3 has hit the ground running — at least in the U.S. and Japan, and in fairly measured quantities — we might finally piece together some more solid information about running Linux on this little box and the exposed programming capabilities


Sony PlayStation 3 controller

Based on earlier blog and forum hearsay, I got the impression that there was some hackish method for getting Linux onto a PS3. It turns out that it’s not a hack, it’s a menu option. The user can install an “other OS” from basically any media format that the PS3 supports (a huge array of optical discs, compact flash, USB media device, and some others).

I’m still searching for actual programming information. Hearsay indicates that X11 will work by rendering to a framebuffer. No word of graphical capabilities beyond that. Still wondering about audio output, controller input, network I/O, and programming multiple Cell SPEs.

Meanwhile, the online user manual contains lists of video and audio formats that the PS3 already knows how to play (and here are the still image formats).

Since I am fascinated with the idea of programming game consoles (even modern ones that increasingly resemble boring, regular PCs), I will be keeping an eye on what people are doing with Linux on PS3. I won’t lose my mind trying to be an early, early adopter of this latest console. I’ll consider purchasing one only when I can walk into a typical store and pick one up off the shelf like a normal consumer; no sooner.

RISC RE

I sometimes hypothesize about reverse engineering code compiled for alternate (i.e. non-x86) CPU architectures. It makes one question why so much effort is focused on x86 RE (to which the simple and immediate answer is, because all the interesting code is compiled for the x86 architecture). Maybe I’m just enamored at how neat RISC code tends to be, with typical architectures featuring 32-bit instruction words. Writing a disassembler obviously embodies not even a fraction of the complexity of a decent x86 disassembler. Fortunately, the GNU binutils take care the disassembly details already (I recently posted a Wiki page on using objdump, even cross-compiling for non-native architectures). Here is some representative disassembly from a PowerPC ELF binary, for those who have never been exposed:

   16b40:       80 e1 01 14     lwz     r7,276(r1)
   16b44:       7c 09 3a 14     add     r0,r9,r7
   16b48:       7d 3e 00 ae     lbzx    r9,r30,r0
   16b4c:       55 20 e1 3e     rlwinm  r0,r9,28,4,31
   16b50:       48 00 00 08     b       16b58
   16b54:       38 00 00 0f     li      r0,15
   16b58:       2c 0b 00 0f     cmpwi   r11,15
   16b5c:       7c 04 03 78     mr      r4,r0
   16b60:       40 82 00 54     bne-    16bb4
   16b64:       88 19 00 02     lbz     r0,2(r25)

Quite a change from the typical x86 slop. Though I sometimes wonder what the ‘reduced’ in reduced instruction set computer (RISC) is really supposed to mean. It definitely doesn’t indicate reduced functionality for individual instructions. I looked up that rlwinm instruction: Rotate Left Word Immediate Then AND with Mask. I started to wonder if it would be simpler to compose an assembly re-targeter for a RISC CPU until I started reading up on this instruction.

And here’s some MIPS RISC code:

  20157c:       84820002        lh      v0,2(a0)
  201580:       2484000a        addiu   a0,a0,10
  201584:       44820000        mtc1    v0,$f0
  201588:       46800020        cvt.s.w $f0,$f0
  20158c:       46010002        mul.s   $f0,$f0,$f1
  201590:       e4600000        swc1    $f0,0(v1)
  201594:       0501fff2        bgez    t0,0x201560
  201598:       24630008        addiu   v1,v1,8
  20159c:       1000000a        b       0x2015c8
  2015a0:       3c020000        lui     v0,0x0

As memory serves, with MIPS CPUs, you get the added fun of manually tracking in your brain the CPU pipelining. I.e., an arithmetic operation from one instruction may not be completed by the next instruction, which happens to operate on the same register, and the compiler was specifically counting on that, and you need to count on it as well during your RE efforts.

Unnamed RE Project

“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.

Continue reading →