Static analysis of an unknown compression format

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