Originally, I was building this hypothetical video codec around old 8-bit NES videos. However, my Old Skool gaming colleague, Trixter, suggested that I think more generally and design the codec around video output from 1st and 2st generation gaming consoles. For reference, these generations are defined as:

• 1st-generation: Atari 2600/5200/7800, Intellivision, Colecovision, Nintendo Entertainment System, Sega Master System, etc. 1976-1988
• 2nd-generation: Sega Genesis/CD/32X, Super NES, TurboGrafx-16, Neo Geo. 1989-1993

Writing about this codec idea is so much fun because I get to use colorful video game screenshots. For example:

U.N. Squadron, Super Nintendo

Golden Axe, Sega Genesis

Read the rest of this entry »

[a continuation of Custom NES Video Codec]

Data compression is all about analyzing the nominal characteristics of a particular type of data and understanding how that data can best be coded using the least amount of information. Let’s look at some of the characteristics of NES video:

Fun NES Screenshots:
Battletoads	Blaster Master

Read the rest of this entry »

Thanks for Benjamin Larsson for advising me on how to make a proper graph using Graphviz (specify a graph of type ‘prof’ vs. ‘unix’). Thus, here are some nice (and big) graphs based on the call/ret experiment at this point:

• wmv2init() callgraph
• wmv2packet() frame #0 decode callgraph
• wmv2packet() frame #18 decode callgraph

See this post (“Refining The call/ret Monitor”) for details on how the graph data is generated.

And as a bonus, I put the toolset to work analyzing Linspire’s WMV3/WMV9 decoding module. Here are some call graphs (I used the teaser trailer from Halo 2, hence the “halo2” in the filenames):

• wmv3init() callgraph; I like the way the graph expresses countless functions invoking wmvMalloc() which simply calls malloc()
• wmv3packet() frame #0 decode callgraph; note that this is just a plain, black I-frame and does not exercise a lot of the logic in the module; let’s start small

Reverse engineering is, of course, a tedious, time-consuming, and error-prone task. It requires a lot of concentration that I either do not have or do not care to invest in the RE task. That is why so many of my RE experiments are geared toward automating the task as much as possible. To that end, I am optimistic about this call/ret monitoring experiment since it yields such a good high-level overview of an algorithm contained in a binary (with debug symbols). But it can use some improvement(s):

Read the rest of this entry »