By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,440 Members | 1,872 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,440 IT Pros & Developers. It's quick & easy.

executable comparisons - md5sum, etc.

P: n/a
jwb
Hello all,

I just was wondering if any one knows how to compare compiled VB.NET
executables to determine whether or not they are identical. In the dark ages
(read: pre-CLR and .NET) one could simply compute the md5sum of a binary and
determine if it was identical to another file. However, under the .NET
framework, this has changed; building an executable twice will result in two
different sums!

I need a quick and reliable way to verify if two files are the same, and I
cannot rely on the version numbers, for a few reasons. One is that they
change build to build, and two is that I do not want to have to rely on
manually setting the version information in the AssemblyInfo file.

Any help/information would be greatly appreciated.

jwb
Jul 19 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
> I just was wondering if any one knows how to compare compiled VB.NET
executables to determine whether or not they are identical. In the dark ages (read: pre-CLR and .NET) one could simply compute the md5sum of a binary and determine if it was identical to another file. However, under the ..NET framework, this has changed; building an executable twice will result in two different sums!
If they are two different sums, then they aren't identical are they?
Are you building with a version number like "1.0.*.*"?

-mike

I need a quick and reliable way to verify if two files are the same, and I cannot rely on the version numbers, for a few reasons. One is that they change build to build, and two is that I do not want to have to rely on manually setting the version information in the AssemblyInfo file.

Any help/information would be greatly appreciated.

jwb

Jul 19 '05 #2

P: n/a
jwb
Mike-

I know that if the sums are different that the files are different... what I
do not understand is how the same source code, built with the same settings
twice, produces two "different" executables.
I have modified the AssemblyInfo version (removing the '*' so that it is not
automagically generated), but this still produces different sums.

My question really is this: Do the .NET compilers (Visual Studio or command
line) embed metadata in executables, and if so, how do I remove it? I need a
way to compare two executables and be certain that they are the same.
Unfortunately, due to some black magic in the .NET framework, I am unable to
do this in the same fashion that I am accustomed to, i.e. md5 sums.

Also, the binaries in question are .exe files, not dlls or assemblies, so I
do not think that this has to do with signing or any other versioning
component that I can think of.

-jwb

"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
I just was wondering if any one knows how to compare compiled VB.NET
executables to determine whether or not they are identical. In the

dark ages
(read: pre-CLR and .NET) one could simply compute the md5sum of a

binary and
determine if it was identical to another file. However, under the

.NET
framework, this has changed; building an executable twice will

result in two
different sums!


If they are two different sums, then they aren't identical are they?
Are you building with a version number like "1.0.*.*"?

-mike

I need a quick and reliable way to verify if two files are the same,

and I
cannot rely on the version numbers, for a few reasons. One is that

they
change build to build, and two is that I do not want to have to rely

on
manually setting the version information in the AssemblyInfo file.

Any help/information would be greatly appreciated.

jwb


Jul 19 '05 #3

P: n/a
I see the MVID is different each time the CSC compiler generates an
executable. As well, offets 88 and 89 seem to change on each compile.
Use FC to check this.

I'm not sure why you can't use the built in versioning. Anyways, if
you want to check the "executable" section, you could zero out the
MVIDs and offsets 88 and 89. That's a lot of work The MVID comes
after (a few bytes or immeadiately) the US table in the metadata.

Can you tell us what you are trying to accomplish? There is most
likely a solution that doesn't require you to get comy with the PE
format and the .NET metadata on-disk representation.

-mike
MVP

"jwb" <jw******@sbcglobal.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Mike-

I know that if the sums are different that the files are different... what I do not understand is how the same source code, built with the same settings twice, produces two "different" executables.
I have modified the AssemblyInfo version (removing the '*' so that it is not automagically generated), but this still produces different sums.

My question really is this: Do the .NET compilers (Visual Studio or command line) embed metadata in executables, and if so, how do I remove it? I need a way to compare two executables and be certain that they are the same. Unfortunately, due to some black magic in the .NET framework, I am unable to do this in the same fashion that I am accustomed to, i.e. md5 sums.

Also, the binaries in question are .exe files, not dlls or assemblies, so I do not think that this has to do with signing or any other versioning component that I can think of.

-jwb

"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
I just was wondering if any one knows how to compare compiled VB.NET executables to determine whether or not they are identical. In the
dark ages
(read: pre-CLR and .NET) one could simply compute the md5sum of
a binary and
determine if it was identical to another file. However, under
the .NET
framework, this has changed; building an executable twice will

result in two
different sums!


If they are two different sums, then they aren't identical are they? Are you building with a version number like "1.0.*.*"?

-mike

I need a quick and reliable way to verify if two files are the
same, and I
cannot rely on the version numbers, for a few reasons. One is
that they
change build to build, and two is that I do not want to have to
rely on
manually setting the version information in the AssemblyInfo

file.
Any help/information would be greatly appreciated.

jwb





Jul 19 '05 #4

P: n/a
Thank you for this info. Let me check some things and see what we can
do.

-mike
MVP

"jwb" <jw******@sbcglobal.net> wrote in message
news:hl****************@newssvr27.news.prodigy.com ...
I am currently not able to use the built-in versioning due to the fact that my client is in the bio-pharmaceutical field and needs to have a way to validate (identify) the installed binaries versus the binaries made from the sourcecode in version control. As these version numbers can either be hard-coded or automagically change, I don't have a real soild way to prove that two binaries are the same.

To put my situation in another light: In the past, when one of my client's systems was to be installed it had to be validated (i.e. prove that the installed system was built from a given revision of the source code in version control); this would be verified by taking an md5sum of the
installed binary and comparing it to the md5sum from the "version control build" binary - hence my original request.

Since I either have to rely on the version number automagically changing (bad because I cannot predict what it'll be, as it changes build to build), or otherwise depend on manually revving the version number (which I may forget to rev), I am still without a definite way of determining whether or not two binaries are in fact the same (regardless of all of the versioning and metadata nonsense). So the difficulty lies in the standards of my client's version control wishes and the requirement of software installation validation, and reconciling built software with sourcecode. If there was a simple PE-only comparison to be made, I'd be happy. I'm just surprized that no one else has found themselves in a similar situation.

-jwb

"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:uQ**************@TK2MSFTNGP12.phx.gbl...
I see the MVID is different each time the CSC compiler generates an executable. As well, offets 88 and 89 seem to change on each compile. Use FC to check this.

I'm not sure why you can't use the built in versioning. Anyways, if you want to check the "executable" section, you could zero out the
MVIDs and offsets 88 and 89. That's a lot of work The MVID comes
after (a few bytes or immeadiately) the US table in the metadata.

Can you tell us what you are trying to accomplish? There is most
likely a solution that doesn't require you to get comy with the PE
format and the .NET metadata on-disk representation.

-mike
MVP

"jwb" <jw******@sbcglobal.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Mike-

I know that if the sums are different that the files are

different... what I
do not understand is how the same source code, built with the same
settings
twice, produces two "different" executables.
I have modified the AssemblyInfo version (removing the '*' so
that it is not
automagically generated), but this still produces different
sums.
My question really is this: Do the .NET compilers (Visual Studio or command
line) embed metadata in executables, and if so, how do I remove
it? I need a
way to compare two executables and be certain that they are the

same.
Unfortunately, due to some black magic in the .NET framework, I
am unable to
do this in the same fashion that I am accustomed to, i.e. md5
sums.
Also, the binaries in question are .exe files, not dlls or

assemblies, so I
do not think that this has to do with signing or any other

versioning
component that I can think of.

-jwb

"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message news:%2****************@TK2MSFTNGP12.phx.gbl...
> > I just was wondering if any one knows how to compare compiled VB.NET
> > executables to determine whether or not they are identical.
In the
> dark ages
> > (read: pre-CLR and .NET) one could simply compute the md5sum
of a
> binary and
> > determine if it was identical to another file. However,
under the
> .NET
> > framework, this has changed; building an executable twice
will > result in two
> > different sums!
>
> If they are two different sums, then they aren't identical are

they?
> Are you building with a version number like "1.0.*.*"?
>
> -mike
>
>
> > I need a quick and reliable way to verify if two files are

the same,
> and I
> > cannot rely on the version numbers, for a few reasons. One
is that
> they
> > change build to build, and two is that I do not want to have
to rely
> on
> > manually setting the version information in the
AssemblyInfo file.
> >
> > Any help/information would be greatly appreciated.
> >
> > jwb
> >
> >
>
>



Jul 19 '05 #5

P: n/a
jwb
Any luck? I appreciate you looking into this for me.

-jwb

"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:eM**************@TK2MSFTNGP10.phx.gbl...
Thank you for this info. Let me check some things and see what we can
do.

-mike
MVP

"jwb" <jw******@sbcglobal.net> wrote in message
news:hl****************@newssvr27.news.prodigy.com ...
I am currently not able to use the built-in versioning due to the

fact that
my client is in the bio-pharmaceutical field and needs to have a way

to
validate (identify) the installed binaries versus the binaries made

from the
sourcecode in version control. As these version numbers can either

be
hard-coded or automagically change, I don't have a real soild way to

prove
that two binaries are the same.

To put my situation in another light: In the past, when one of my

client's
systems was to be installed it had to be validated (i.e. prove that

the
installed system was built from a given revision of the source code

in
version control); this would be verified by taking an md5sum of the
installed binary and comparing it to the md5sum from the "version

control
build" binary - hence my original request.

Since I either have to rely on the version number automagically

changing
(bad because I cannot predict what it'll be, as it changes build to

build),
or otherwise depend on manually revving the version number (which I

may
forget to rev), I am still without a definite way of determining

whether or
not two binaries are in fact the same (regardless of all of the

versioning
and metadata nonsense). So the difficulty lies in the standards of

my
client's version control wishes and the requirement of software

installation
validation, and reconciling built software with sourcecode. If there

was a
simple PE-only comparison to be made, I'd be happy. I'm just

surprized that
no one else has found themselves in a similar situation.

-jwb

"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:uQ**************@TK2MSFTNGP12.phx.gbl...
I see the MVID is different each time the CSC compiler generates an executable. As well, offets 88 and 89 seem to change on each compile. Use FC to check this.

I'm not sure why you can't use the built in versioning. Anyways, if you want to check the "executable" section, you could zero out the
MVIDs and offsets 88 and 89. That's a lot of work The MVID comes
after (a few bytes or immeadiately) the US table in the metadata.

Can you tell us what you are trying to accomplish? There is most
likely a solution that doesn't require you to get comy with the PE
format and the .NET metadata on-disk representation.

-mike
MVP

"jwb" <jw******@sbcglobal.net> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
> Mike-
>
> I know that if the sums are different that the files are
different... what I
> do not understand is how the same source code, built with the same settings
> twice, produces two "different" executables.
> I have modified the AssemblyInfo version (removing the '*' so that it is not
> automagically generated), but this still produces different sums. >
> My question really is this: Do the .NET compilers (Visual Studio or command
> line) embed metadata in executables, and if so, how do I remove it? I need a
> way to compare two executables and be certain that they are the
same.
> Unfortunately, due to some black magic in the .NET framework, I am unable to
> do this in the same fashion that I am accustomed to, i.e. md5 sums. >
> Also, the binaries in question are .exe files, not dlls or
assemblies, so I
> do not think that this has to do with signing or any other
versioning
> component that I can think of.
>
> -jwb
>
> "Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message > news:%2****************@TK2MSFTNGP12.phx.gbl...
> > > I just was wondering if any one knows how to compare compiled VB.NET
> > > executables to determine whether or not they are identical. In the
> > dark ages
> > > (read: pre-CLR and .NET) one could simply compute the md5sum of a
> > binary and
> > > determine if it was identical to another file. However, under the
> > .NET
> > > framework, this has changed; building an executable twice will > > result in two
> > > different sums!
> >
> > If they are two different sums, then they aren't identical are
they?
> > Are you building with a version number like "1.0.*.*"?
> >
> > -mike
> >
> >
> > > I need a quick and reliable way to verify if two files are the same,
> > and I
> > > cannot rely on the version numbers, for a few reasons. One is that
> > they
> > > change build to build, and two is that I do not want to have to rely
> > on
> > > manually setting the version information in the AssemblyInfo file.
> > >
> > > Any help/information would be greatly appreciated.
> > >
> > > jwb
> > >
> > >
> >
> >
>
>



Jul 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.