Reverse engineering.

[CrackWizard]

Okay. I play a game called chain of command. It's abandonware, the original designers went bankrupt and the source code got lost. The server and game files and such were all on a backup server and acquired from one of the original designers. I was just told we need to reverse engineer an .odf file in order to fix some glitches and enhance the game. I have the code in a hexadecimal format. Now I'm a complete n00b when it comes to programming in general. I have an old version of Borland C++ and a lot of time on my hands so I figured I'd give a crack at doing some decoding. The dude that does most of the programming for the game gave me some helpful hints but I really would appreciate if someone could help push me in the right direction.

I've figured out how to convert hex to binary. Is there a specific way to interpret that binary. Or is there a better way of deciphering it and turning it to code.

Or hell, even a program to do it?

Or am I just babbling a bunch of nonsensical banter. In other words, could someone give me a general outline of what I need to research/learn, then what I need to do.

[Nick Evan]

You need a decompiler, but all the decompilers I've tried so far give crappy code (if any). Boomerang might be a place to start

[Salem]

So is the ODF like a save game file format or a map format?

[CrackWizard]

I was told that the exe file uses it to run the game. I am using PsPad to decompile.

[Necrolis]

you might also want to use a debugger like ollydbg to trace through the code relating to the file access, just break on the fread calls etc and then stick a memory break on the files "image"/memory block, and see how its treated

[CrackWizard]

I can't open it using ollydbg. I'm assuming that is important because of the lack of source code?

[Necrolis]

No, you need to run the game and attach to the running process, then follow the loading routines for those files and memory breakpoint one, play till the break trips and see how the code utilizes them