Results 1 to 7 of 7

Thread: Looking into .obj files rather than the .exe

  1. #1
    Mother
    Guest

    Looking into .obj files rather than the .exe

    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
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    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

  3. #3
    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

  4. #4
    DakienDX
    Guest
    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)
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #5
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647

    Explanation

    Cyberheg

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

  6. #6
    Mother
    Guest
    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
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  7. #7
    Thigo
    Guest
    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
    I promise that I have read the FAQ and tried to use the Search to answer my question.

Similar Threads

  1. ida 5.6 against ida 5.5 idb files..
    By Shub-nigurrath in forum Tools of Our Trade (TOT) Messageboard
    Replies: 5
    Last Post: February 25th, 2010, 16:20
  2. Replies: 4
    Last Post: January 18th, 2008, 01:24
  3. files .INX
    By NoLOcKīs in forum Malware Analysis and Unpacking Forum
    Replies: 1
    Last Post: June 29th, 2005, 13:02
  4. .TIL files in IDA Pro 4.1.5 and above...
    By Aimless in forum Tools of Our Trade (TOT) Messageboard
    Replies: 1
    Last Post: January 2nd, 2002, 16:42

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •