reversing a PE file into it's obj's?

[Sam111]

Is it possible to go the other way.

PE .exe ---> linker (or some program to reverse engineer ) ----> obj's that where used to create the PE .exe.

I would think this is not possible.
Unless their was a symbol table in the PE that held the names and address of the function's and the obj files they where linked from?

I am just curious if it is possible and if so how it is done?

I am really think it is a one way thing
obj's -->linker -->PE .exe .

But you can always disassembly the sections. So you always have the code,data,...etc but I am wondering if you can put them back into their obj's. Like given a random .exe file can you send it to a program that gives you back the obj files that where used to link to that .exe file.

Also is their away with VS 2005 to have your c/c++ code assembly to assembly source code. Then customize it and compile with masm to your PE or bin or whatever.... ?

Same question but with gcc/ld ? Can you compile your c/c++ code to asm source instead of compiling to machine code automatically.

Thanks for any input.

[ru2aqare]

Is it possible to go the other way.

Why would you want that? Theoretically it's possible - disassemble the executable file and separate each function. However I fail to see the practical use of it.

Also is their away with VS 2005 to have your c/c++ code assembly to assembly source code. Then customize it and compile with masm to your PE or bin or whatever.... ?

What you are looking for is a "compile only, don't link" option. In the case of msvc, there is a way to have msvc output assembly source. Go to project properties -> C/C++ compiler -> output files -> assembler output and specify what you want. I usually use "Assembly, Machine and Source Code (/FAcs)" settings. The resulting assembler source is not compatible with any assembler though, however it should be possible to convert it to what format masm accepts.

Same question but with gcc/ld ? Can you compile your c/c++ code to asm source instead of compiling to machine code automatically.

I'm sure there is a similar option. If I remember correctly it is /c /s or something.

[Sam111]

Why would you want that? Theoretically it's possible - disassemble the executable file and separate each function. However I fail to see the practical use of it.

Because I am just curious if it is a one way process?
Ya, but then how do you know what functions go into what obj's and what the names of the linked obj's where?

Sure you can disassembly every function but how do you know where they go !
I would think the only way is by a symbol table but that doesn't have to be in the PE.

What you are looking for is a "compile only, don't link" option. In the case of msvc, there is a way to have msvc output assembly source. Go to project properties -> C/C++ compiler -> output files -> assembler output and specify what you want. I usually use "Assembly, Machine and Source Code (/FAcs)" settings. The resulting assembler source is not compatible with any assembler though, however it should be possible to convert it to what format masm accepts.

So even if I compile to assembly source. I couldn't take the asm and compile to a PE or Bin using masm?
I would think masm could handle VS2005 asm source without having to modify the source?

Anyway I am wondering what I would have to changed in the asm source to get masm to compile it.

[AJ]

I would think the only way is by a symbol table but that doesn't have to be in the PE.

If the information isn't there, you can't get it. You can only extract symbol names and values if there's a symbol table.

Cheers,
Adam

[Sam111]

I am just curious on what the percentage's of exe that have enough info to reverse engineer it to obj's.

I.E how many exe have symbol tables in them. 1 out of 10 , 1 out 100 ,... approximately.

Anybody know how common it is for an exe to have a symbol table.


But in any case if it doesn't have a symbol table you cann't go back to the obj's. I got you on that. That is what I was suspecting though I wanted to be 100% sure.

Their is no other way you can get the obj file names and their functions from the linked .exe file?

Also is their away to tell gcc/ld to produce intel asm source I have been getting AT&T Syntax source code. And prefer use intel syntax never really did to much with AT&T syntax. But if their is noway I guess it will be ok.

[AJ]

Hi,

I am just curious on what the percentage's of exe that have enough info to reverse engineer it to obj's.

I don't know how you would make an accurate guess, but as far as I'm concerned, a debug compile produces an executable with symbols and a release compile produces an executable without symbols - except those required for dynamic linking.

But in any case if it doesn't have a symbol table you cann't go back to the obj's. I got you on that. That is what I was suspecting though I wanted to be 100% sure.
...
Their is no other way you can get the obj file names and their functions from the linked .exe file?

Are you clairvoyant?

Cheers,
Adam

[Sam111]

Also is their away to tell gcc/ld to produce intel asm source I have been getting AT&T Syntax source code. And prefer use intel syntax never really did to much with AT&T syntax. But if their is noway I guess it will be ok.

[JohnnyTheDon]

What do you mean by 'produce'? They both produce regular machine code, which isn't Intel or AT&T syntax, its just binary. If you want to use intel syntax in inline assembly for gcc, just google for it.

[ru2aqare]

I am just curious on what the percentage's of exe that have enough info to reverse engineer it to obj's.

I.E how many exe have symbol tables in them. 1 out of 10 , 1 out 100 ,... approximately.

Anybody know how common it is for an exe to have a symbol table.

All (*all*) PE executables had their symbols stripped that I came across. Maybe a few ones compiled on Cygwin had some sort of obscure symbol-table-looking-thingy. The current MS recommendation is that debug information should be in a Program Database (PDB) file separately, and linkers follow suit. This information can be queried by the PDB API, as far as I know.

Their is no other way you can get the obj file names and their functions from the linked .exe file?

If the information is not there, you can't get it. But you can guess it - give the object files random names (like Function<hash of code>.obj). But why does the name of the object file matter? More than that, why would you want to extract object files from an executable?

[Sam111]

Ya, I see you really cann't reverse PE into obj's but again why would you want to. I agree their is no need to every have to reverse engineer to obj's.
Except for the possibility of being able to relink the obj's and add a few of your own obj's with an entry point to your code... Kind of like an exe binder. But I guess you could just throw all the functions into one obj and then use ld with that obj and your added obj files ...etc

What do you mean by 'produce'? They both produce regular machine code, which isn't Intel or AT&T syntax, its just binary. If you want to use intel syntax in inline assembly for gcc, just google for it.

I meant when you compile with gcc noassemble you get the asm source in at&t syntax.
I was wondering if you could get gcc to produce the asm source in intel syntax.

[JohnnyTheDon]

The-masm option (ie -masm=intel) does this. Note that this doesn't work on some platforms.

[mrnoob]

afaik, you cant separate a PE into each of its individual source objs, but with a disassembler you can disassemble the source into a single ASM source which you could then extend, although the symbol labels would likely be randomly generated. As for compiling C/++ source to assembly, simply add the -c switch to the command line. For turning AT&T into intel syntax, as far as i know youll have to do that yourself, although there may be tools/switches to do it for you.

[Solar]

As for compiling C/++ source to assembly, simply add the -c switch to the command line.

• -E to preprocess without compilation (output is source with comments removed and includes included),
• -S to compile without assemblation (output is assembler source, but see (*) below),
• -o to compile and assemble without linking (output is object file).

For turning AT&T into intel syntax, as far as i know youll have to do that yourself, although there may be tools/switches to do it for you.

• gcc -masm=att -S test.c # gives AT&T disassembly
• gcc -masm=intel -S test.c # gives Intel disassembly

(*): GCC does not generate this ASM and feeds it to the assembler in a normal compile run; this source is reverse-generated from a binary representation that is normally fed to the assembler backend.

[Sam111]

Ok , got it.

One more related question I have
Is the obj file format in coff or xcoff or PE/coff.
Like .o files are probably in a different format then microsoft obj extension. Would it be possible to take .obj's and link them with .o files?

I know the .exe , .dll , lib are in PE file format but if obj's are in this format as well then they must contain enough info for the linker to combined into one exe file. Does all the linker need to know is the sections or is their a symbol table for each obj file and it get's not included when in the exe by the linker.

For example
say I have obj1.o obj2.o
obj1 has only 2 functions and nothing else in it (i.e func1 , func2.)
obj2 has only 1 function and nothing else in it (i.e main )

Does the linker put in the
.text section
func1
func2
main ( and the entryaddresspointer gets set to this )

Or is their an order to merging the .data , text ,..etc section's.

What would be the steps that the linker goes thru to produce an exe file?

I am guessing it can add the machine code for the functions in any order to the .text section but it must just keep track of where the rva for the functions are and where the entry point address is. Then it resolves any unresolved or external symbols.

For any external symbol or unresolved symbol in an o file is their a special way to mark a symbol so that you know the difference between a resolved and unresolved symbol. Or does it just make an entry of all the symbols in the o file in some .rdata section and the linker can move the functions around by using the .rdata section.

[ru2aqare]

One more related question I have
Is the obj file format in coff or xcoff or PE/coff.
Like .o files are probably in a different format then microsoft obj extension. Would it be possible to take .obj's and link them with .o files?

Almost all object files you encounter while working on Windows will be in the COFF format (including .o files produced by gcc under Cygwin). So it should be possible to link them together (C++ name mangling is another issue). Object files produced by gcc under *nix may also be usable if gcc produces COFF object files.

I know the .exe , .dll , lib are in PE file format but if obj's are in this format as well then they must contain enough info for the linker to combined into one exe file. Does all the linker need to know is the sections or is their a symbol table for each obj file and it get's not included when in the exe by the linker.

Library (lib) files are not PE files, they are like a special archive file that contains multiple object files (also called archive members). Object files contains symbol tables. PE executable files may contain symbol table, however all linkers seem to remove the symbol table from the executable (and place the debugging information into a separate PDB file).

Or is their an order to merging the .data , text ,..etc section's.

A linker is free to arrange the object files within a given section. So if you have three object files which contain .text sections, the ordering of the object files is up to the linker.

What would be the steps that the linker goes thru to produce an exe file?

I believe I have answered this question previously.