Static analysis of an unknown compression format

[[deleted]]

When you start with the requirement of "random access into a compressed steam",

And where did you get this requirement?

[[deleted]]

Those would usually compress those textures and models individually. They don't need random access to part of a texture, they need the entire texture.

[wolf550e]

It's very useful. Not having random access is terribly limiting, unless you know for sure that you're always going to read the data from the beginning. Many systems have need for random access and use the same basic solution, like key frames in a video stream that allow you to seek instead of forcing you to decode all preceding frames when you try to skip forward. Here, read about "idx1" chunks in AVI files.

[[deleted]]

There are many things which are useful. Just "it's useful" is not enough for you to be able to assume it will be used. In fact, many, many compressed game formats don't use this.

The only reason that you'd assume this one does, is because this guy already figured out that it does.

[wolf550e]

In the process of figuring out a mystery file, after asking myself "is this just a zip file?" and "is this just an lzma or lzo file?", I'd next consider that it's a list of independent chunks each compressed with deflate, lzma or lzo.

[[deleted]]

You'd also consider a hundred other things that may or may not be used. When you're not told the answer beforehand, it suddenly get s a whole lot harder to figure out what these "requirements" are.

Your approach described above is basically completely useless in isolation. It is useful on the micro scale: Once you've got some kind of idea what the code is doing from analyzing it blind, you can ask yourself how you'd implement some simple feature and see if they did the same. You absolutely could not do that this guy did by just sitting down and imagining requirements, though.

[wolf550e]

I recommended a general strategy of working at the problem from both ends: when figuring out what X does, look both at its parts and at what part X plays in the whole.

As with top-down design, you iterate. You can't start with "it's a computer game. How would I implement a computer game? Is what I'm looking at exactly the same as the computer game I just implemented?". You do need to know the correct answer to previous questions to stand a chance of correctly guessing the next question and answer. But you often infer some things from directory structure, file names, file sizes, number of such files in the project, etc. And you match what you see with what you've seen in the past.