7

So I know x86 machine language and C++/C language. In the last weeks I've dedicated to learn Windows internals and especially PE format. My target is retrieving the Tomb Raider The Angel of Darkness source code files. This is 3d video game released 10 years ago (2003) and written in both C and C++ language. The code was both compiled with VC++ 6.0 and Intel C++ 7.1. The files from which I'm trying to guess the inital source code are PE formated executables with included ProgramDataBase file (v2.0) with public symbols. Their names are TRAOD, TRAOD_P3 and TRAOD_P4 (excluding the file extension (.exe.PDB) as the first one is compiled with vc++ and the other ones with ic++ for respectively Pentium 3 and Pentium 4 target processors.

I was using IDA Pro to open the executables and map the PDB symbols. Then I was translating the machine instructions to their C++ equivalents and trashing them into one big cache file. Then I was using dbh.exe to map the functions into their matching source files (because the PDB files had the source line information for the public functions). But before to move to the next function I was compiling at test executable with vc++ or ic++ containing that function and then comparing the results with the original one (I mean comparing the machine code equivalent of the target function with both my test exe and the game one). But then I thought this isn't so much efficient because many other process aren't considered. I mean the PDB file holds much more information than the dbh program dumps and the PE file maybe too. In articles about the PE file format it's said that it's much simillar to the .OBJ one which files are used by the linker to produce the exe. So is it a better idea to go through the .OBJ files and then to guess the source code or just work with the exe? I read also that for producing .OBJ files from PE you need to have some symbols and I have them from the PDB file so I think this conversion is possible. Also if you have any other ideas how to decompile this game share them - I really want to achieve this.

EDIT: I'm also searching a documenation aobut the .PDB format(v2.0) and about the VC++ 6.0 produced .OBJ and .LIB files.

  • 1
    Regarding decompilation of machine code executables, and why this is not an easy task, see this question. – Rolf Rolles Jul 14 '13 at 8:51
4

If you are interested in really digesting the PE format, you definitely want to have a look at the references available here: http://blog.dkbza.org/2012/08/pe-file-format-graphs.html

Those diagrams are wonderfully complete and will absolutely give you an enormous leg up when it comes to analyzing an unknown file in PE format, even if the headers have been tampered with to discourage RE.

  • Hmm a strange explanation. By the way I would like to have some documentation about the .PDB file format (v2.0) excluding the book "Windows 2000 Undocumented secrets" where I already read it's description but unfortunately isn't full(Nowhere there is said what the first stream actually represents.). Also I would like to know more about the VC++ 6.0 produced .OBJ and .LIB files. Thanks. – sasho648 Jul 14 '13 at 8:40
5

If you purpose to reverse engineer the game is order to learn the way it was made you will most likely end up having C/C++ files recreated (at least of major components). I am afraid there is no way you can reverse something and have full understanding of internal workings without firm grip on assembly. There are several tool that could aid you in your work. There are couple of great debuggers that you could use: OllyDBG and Immunity Debugger. There is obviously Hex-Rays, which offers several product. There is IDA, which is excellent multiprocessor dissembler. IDA has 2 version: free version and commercial version. There is also Hex-Rays Decompiler

  • Sorry but no new information here for me. Anyway thanks for the answer. – sasho648 Jul 14 '13 at 8:38
6

Given that you don't already have the .obj files, it doesn't make sense to try to generate the .obj files from the .exe and .pdb files and then reverse engineer the generated .obj files. If you were to do this then the .obj files wouldn't have any information in them that was not already in the .exe or .pdb files. As such, you're better off just working with the .exe and .pdb files.

As for reverse engineering the code, Hex-Rays is very helpful when trying to reverse engineer x86 code back to C/C++ source code.

  • Thanks for the answer but wouldn't it be easier and more organized to decompile each .obj file. I mean that the executable is created not only by .obj files but by .lib files too. Also there are some .obj's which are included in the API's used with the app. So if I work directly with the executable I should distinct what's a user-made code is and what is already coded API function. EDIT: I have already used the Hex-Rays - it helped me a lot by the way. – sasho648 Jul 14 '13 at 8:34
  • So you already have the .obj files? – Jason Geffner Jul 14 '13 at 17:20
  • No but I think I could be able to extract them (their file names are stored in the PDB file ans I suspect that also their part in the PE file is described too but unfortunately I can't find a good explanation of it's format - the PDB one). My point is that decompiling and testing small portions of the executable could be a lot easier then compiling a whole test executable. – sasho648 Jul 14 '13 at 17:45
  • 2
    So it sounds like you're now asking how to extract information from PDB files. You're probably better off starting a new question, since your original question was already answered. FWIW though, see here for the values that can be extracted from a PDB: msdn.microsoft.com/en-us/library/4sy4ebfw.aspx – Jason Geffner Jul 14 '13 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.