T2'05 was interesting, it's more of a challenge in which you need to figure out *what* the program is doing, as opposed to *how* it is doing it. Figure out the [what] and the [how] becomes easier.
T2'06 however...that seems more the opposite. I have a feeling, I think, of [what] the challenge is doing, the difficulty lies in determining the [how]. In one portion it makes several (as in thousands not hundreds) of indirect calls to a table of call addresses (about 60 of them but many duplicated). This indirect call seems to play a pivotal role in the challenge.
I've been trying to figure out a method of automated analysis in order to pull out a pattern in the calls. I wrote an Ollyscript which logged the stack return address and parameter values for the call table addresses. This helped a little bit in that I could see there was a pattern, though I could make no immediate sense of it.
I suspect many of the calls are red herrings/diversions and do nothing useful unless the parameters are just right, so what I'm trying to do is find out where to focus attention.
I've also tried ProcessStalker, this may prove useful but again it is difficult to interpret the results.
I would like to be able to come up with some form of automated analysis which could help clarify the code execution, mostly to see if it *can* be done and so it could be applied to other situations where indirect calls to a call table is used for example.
Ultimately the solution may be in repeated tracing until the little lightbulb goes on over your head and the Zen kicks in
I'm curious just in general if anyone else has any success stories in using automated analysis, be it plugin, script or standalone tool, for a real-life reversing problem. Yeah I know there are a million ollyscripts for find the OEP of every packer under the sun, but I'm thinking of anything
other than that!
Cheers,
Kayaker
