PE linker version

[d***@yahoo.com]

I need to remove the compiler version information from the PE header
of a bunch of executables.

I have found a number of tools that allow me to tell which compiler
was used but I have not found one that allows me to delete that
information.

Any help would be most appreciated.

[d***@yahoo.com]

Ok.

It is not MajorLinkerVersion or MinorLinkerVersion only.

Apparently the complier also identifies itself somewhere else in the
PE header.

[Liviu]

Post by d***@yahoo.com
It is not MajorLinkerVersion or MinorLinkerVersion only.

No surprise that the compiler wouldn't put its version info under
the linker fields.

Post by d***@yahoo.com
Apparently the complier also identifies itself somewhere else
in the PE header.

That's a bit more complicated, since a PE has only one header,
but may include objects built with different compilers, or none at all
for that matter.

If you really need to remove _all_ compiler info from the executable,
then get a decent PE editor and delete all sections named ".text" or
marked as "E". To be paranoidly sure, do the same for ".*data" and
"R/W" since sneaky compilers have been known to leave traces in
those sections, too.

;-)

[Joseph M. Newcomer]

In reading this, I wonder if the goal is to hide the use of gcc so that no one can request
the source code. If this were true, it would be exceptionally poor business practice,
because the code is sufficiently valuable, then a non-GNU compiler is affordable. It
doesn't necessarily have to be VS.
joe

Post by Liviu

Post by d***@yahoo.com
It is not MajorLinkerVersion or MinorLinkerVersion only.

No surprise that the compiler wouldn't put its version info under
the linker fields.

Post by d***@yahoo.com
Apparently the complier also identifies itself somewhere else
in the PE header.

That's a bit more complicated, since a PE has only one header,
but may include objects built with different compilers, or none at all
for that matter.
If you really need to remove _all_ compiler info from the executable,
then get a decent PE editor and delete all sections named ".text" or
marked as "E". To be paranoidly sure, do the same for ".*data" and
"R/W" since sneaky compilers have been known to leave traces in
those sections, too.
;-)

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Liviu]

Post by Joseph M. Newcomer
In reading this, I wonder if the goal is to hide the use of gcc so
that no one can request the source code.

GCC and its runtime libs can be used to compile and deliver closed
source commercial apps (within common sense, such as not attempting to
resell a recompile of itself, or other silly things along that line).

I won't venture to second guess the reason behind OP's question,
since it displayed such deep confusion between compiler/linker/pe/etc
as to make whatever original motive moot ;-)

Liviu

[Joseph M. Newcomer]

This post might be inappropriate. Click to display it.

[Liviu]

Post by Joseph M. Newcomer
I thought there was serious confusion, myself, so I checked using
dumbpin ./all the only suggestion that the Microsoft compiler might
have been used was a set of import records from MSVCR90D.DLL.

That's a tell-tale sign, indeed, but even that is not absolute. For
example the MinGW gcc links to MSVCRT but it's certainly not
built with a MS compiler itself.

My guess is that the OP has come across some PE tool claiming to
second guess "the compiler" and did not realize that _the_ compiler
is a hopelessly wrong target to chase at the PE level, as opposed to
object level. I've had PEs made of C++ modules compiled with MSVC,
numerical libraries compiled with ICL and the accidental assembler shim.
It's anybody's guess what one of those wonder PE tools would report as
_the_ compiler in such cases ;-)

Liviu

[Joseph M. Newcomer]

Someone who is familiar with the "idioms" of a particular compiler might, just might, be
able to analyze the code patterns and guess what compiler was used. However, only
optimized code tends to exhibit such characteristics, because only the optimizers make
characteristic transformations. Similarly, you can frequently tell when an assembly-code
module is included, because it uses instructions and idioms no compiler would ever use.
But it takes years of experience across multiple compilers to build this recognition.
Since the only C compiler I've used in the last 20 years is one of the compilers from
Microsoft, I really don't know what the gcc, Intel, etc. idioms are. I suspect a really
powerful "AI" recognizer might have a chance. I can usually tell an assembler module
because its patterns are uncharacteristic of what I know the C/C++ compiler produces. But
beyond that, I don't have the experience in competing compilers to tell the difference.

It is not clear that even if you have the .obj files, you can specifically tell what
compiler generated it (without looking at the code patterns). I looked at a dumpbin of a
.obj file, and nothing really jumped out and said "I was created by the Microsoft
compiler" (there's a reason it is called COFF - "Common Object File Format"--which is that
all compilers generate it, so they interoperate). Again, perhaps someone who studied the
COFF output from several compilers might recognize some idioms, but of course this
information is discarded by the time the .exe file is generated.
joe

Post by Liviu

Post by Joseph M. Newcomer
I thought there was serious confusion, myself, so I checked using
dumbpin ./all the only suggestion that the Microsoft compiler might
have been used was a set of import records from MSVCR90D.DLL.

That's a tell-tale sign, indeed, but even that is not absolute. For
example the MinGW gcc links to MSVCRT but it's certainly not
built with a MS compiler itself.
My guess is that the OP has come across some PE tool claiming to
second guess "the compiler" and did not realize that _the_ compiler
is a hopelessly wrong target to chase at the PE level, as opposed to
object level. I've had PEs made of C++ modules compiled with MSVC,
numerical libraries compiled with ICL and the accidental assembler shim.
It's anybody's guess what one of those wonder PE tools would report as
_the_ compiler in such cases ;-)
Liviu

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[Kira Qian]

Once a execute file is generated, there is no way to reverse it or edit with existed API. I think your question is how to write a program to edit a bunch of PE file. I think you can't. For a single PE file, you can try PE Explorer.

[Joseph M. Newcomer]

Well, if you want to be strict about it, yes, the standard APIs work. They are
CreateFile, ReadFile and WriteFile. I know what you meant, but it isn't exactly what you
said.
joe

Post by Kira Qian
Once a execute file is generated, there is no way to reverse it or edit with existed API. I think your question is how to write a program to edit a bunch of PE file. I think you can't. For a single PE file, you can try PE Explorer.

Joseph M. Newcomer [MVP]
email: ***@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[d***@yahoo.com]

Thank you, everyone, for the replies.