Hi all,

I've got a program for which I have the VC++ .obj files, one header, and resources (enough to compile it). This program has a rather annoying message box which I'd like to get rid of.

My question is: would it be better to simply look at the .exe or does the possesion of the .obj files make life any easier? I've not really reversed projects from their .obj files, just from the compiled .exe, so this is a bit new to me.

Thanks,

Mother

Mom:

Having the .obj files is such an unusual situation in this sort of RCE that I Doubt many people in this forum have ever tried to crack an app from the .obj files. So by mere experience point of view, exe files probably have been addressed more often.

.exe files allow live debugging, .obj files do not.

.obj files are already in object code, but are missing the linking info. You would have to reverse engineer the linking process as well as the app itself.

In one word, I would go for the .exe first

usual or unusual is not the question and is kinda pointless.

When you have the object files you have advantages. Lets say you want to remove this MessageBox permanently then you only need to do it once in the object file and use this obj for every time you compile your programs.
Often objects hold more symbol information which gives alot convienience.

What I would do is look inside this obj to find the offending call. If you won't succed that easily then write your own small test program which would causes this MessageBox to pop up and then you can see which part of the code it is (by comparing the disassembly of the final linked file with the object).

Notice you can also use objects to make signatures for IDA which would make it even easier to work with on linked files.

Maybe naides could explain what he means with "You would have to reverse engineer the linking process as well as the app itself." as this does not really make sense. The code in the object is the same as the linked file where relocations are beeing processed if needed and externals and imported files are matched together.

// CyberHeg

Hello Mother !

Of course an .OBJ file gives more information, but mainly to the linker.

You can't find imported function calls (since the import table isn't build yet, you would just have a "Call [00000000]" and all memory refered pointers are also invalid. If you're looking for a specified "normal" (example 12345678h) value, you can find it in the .OBJ file, but if you're looking for memory locations, the .EXE may have a "Mov EAX, 004F80AC", but the .OBJ might only contain a "Mov EAX, 0ACh" or "Mov EAX, 80ACh" or anything else you might imagine. (ending with ACh probably, but not necessary)

Cyberheg



Yes, I think I used a very poor choice of words. What I meant was that you will have to work, by hand, all the references to static libraries, global variables, resorces and some external functions, which is the job of the Linker. I have not done it, but I figured one may have a harder time following the flow of the program and figuring out calls to the static libraries and other external modules.

OK, thanks for all the replies - after some digging around with your suggestions and comments, I think it's going to be easier looking at the disassembled .exe than the .obj files - the only real advantage of having them is that I can modify resources and recompile.

Cheers,

Mother

LOL
.obj files are fucking usefull when U need to crack sth... from what do you think IDA build sig files ?? From .obj !! You got all the names in the .obj and I think it's enough to crack it... even if u cannot use the debugger. But infact you can, just find a place u find suspect in the obj and seek it in the built exe to trace... once u know how to crack it in the .exe you can do the same in the obj. Very easy