Comparing .NET executable files from two separate build sessions results in different SHAs
-
21 marca 2011 01:47
Hi,
We have a similar issue to the following post:
http://social.msdn.microsoft.com/Forums/en/msbuild/thread/5a658b3c-4678-42ff-a838-ae6c9c98a060
That thread did not really resolve the issue, it just showed how to manually compare the files. We have the same authority (in a different country) to Sean, and we need to fix this. The authority wants to be able to simply run an SHA on the program at the client site, compile the program in their office, and be able to successfully match the SHAs.
For simple Windows C++ native code, the files will differ only by the date/time stamp, and we have a program the authority runs after compiling that sets that to a fixed date (I'll you guess what it is! :^). We do the same thing with the released program prior to installing it, so the two signatures match OK.
From what we can see, if we compile a .NET program or assembly into an exe or DLL, save the file away, rebuild the program/assembly, then compare the 2nd build with the first, the two files don't match.
Examining the two files at the binary level, we can see that the date and the GUID in header have changed, and we can handle that in a similar way to the dates for an ordinary Windows exe. I suspect that the compile user and location will change as well, but again, we can deal with that, so those fields are all OK.
The big problem is that there are a bunch of 16 byte blocks in the raw data section(s) of the files that differ from build to build. Can anyone tell us what those blocks are, what they mean, and if there is a way to easily identify and normalise them, so we can end up with two matching files?
Thanks in advance for the assistance.
- Przeniesiony przez Victor_Chen 23 marca 2011 08:19 SHA different in assembly (From:MSBuild)
Wszystkie odpowiedzi
-
23 marca 2011 08:19
Hi OzFlip,
Thanks for your post.
Actually, I don't think this issue is much relevant to MSBuild,
I suggest to post a new thread at
http://social.msdn.microsoft.com/Forums/en-US/windowssecurity/threads
Hope you can get more information there.
Ziwei Chen [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.

-
24 marca 2011 03:22
Thanks for the reply.
Please let me explain, I don't think it's related to the security.
I create a dll with vs2010, it's only a one class dll, inside that class there's only one field, ie, public int testfield. That is it.
I compile it in the release mode with "none" debug info. Then I run the dumpbin /all /rawdata for the dll, save the output. Recompile the dll again without any changes, run the dumpbin again, then compare the dumpbin outputs, they're different. The first one is the timestamp, that I understand, the 2nd part is in the Raw Data #1 - the 16 bytes raw data are different, that I don't understand.
What are the 16 bytes raw data, why are they different?????
Thanks very much
-
24 marca 2011 04:30"Thanks for your post.
Actually, I don't think this issue is much relevant to MSBuild,
I suggest to post a new thread at
http://social.msdn.microsoft.com/Forums/en-US/windowssecurity/threads
Hope you can get more information there.
Ziwei Chen [MSFT]"
Ummm .. I'm asking what MSbuild is putting into specific areas of compiled .NET code. What could it be more related to? A similar question was addressed in that forum.
Would you please put this back so someone might be able to answer it? I'm trying to be pleasant, but I feel like using a lot of very unpleasant words toward you right now, Ziwei.
-
15 maja 2012 23:18Właściciel
Ummm .. I'm asking what MSbuild is putting into specific areas of compiled .NET code. What could it be more related to? A similar question was addressed in that forum.
Would you please put this back so someone might be able to answer it? I'm trying to be pleasant, but I feel like using a lot of very unpleasant words toward you right now, Ziwei.
I can move it back to MSBuild if you want.
Thanks!
Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)
- Zaproponowany jako odpowiedź przez Ed Price - MSFTMicrosoft Employee, Owner 15 maja 2012 23:18
- Cofnięcie jako propozycji odpowiedzi przez Ed Price - MSFTMicrosoft Employee, Owner 16 maja 2012 00:16
- Oznaczony jako odpowiedź przez Ed Price - MSFTMicrosoft Employee, Owner 16 maja 2012 00:28
- Oznaczenie jako odpowiedzi cofnięte przez Ed Price - MSFTMicrosoft Employee, Owner 16 maja 2012 00:28
-
15 maja 2012 23:31
I opened a post there and got no answer either. This now totals 5 or 6 questions I have asked on MS forums (coding, server, you name it) and I've never once got a useful answer from from anyone. I often wonder what "MVP" stands for.I solved the problem by pulling apart the PE+ format myself and eventually worked it all out and wrote a program (now government audited) to strip the dates and GUIDs out to allow the files to be hashed and compared.
Just as well my own team are a lot smarted than the "MVPs". You guys seem desperate not to have unanswered questions on forums but MS and the "MVPs" never can answer them. So I'll make you all happy and mark my own response as the answer.
Sheesh...
- Zaproponowany jako odpowiedź przez OzFlipper 15 maja 2012 23:31
- Oznaczony jako odpowiedź przez Ed Price - MSFTMicrosoft Employee, Owner 16 maja 2012 00:28
-
16 maja 2012 00:28Właściciel
I opened a post there and got no answer either. This now totals 5 or 6 questions I have asked on MS forums (coding, server, you name it) and I've never once got a useful answer from from anyone. I often wonder what "MVP" stands for.I solved the problem by pulling apart the PE+ format myself and eventually worked it all out and wrote a program (now government audited) to strip the dates and GUIDs out to allow the files to be hashed and compared.
Just as well my own team are a lot smarted than the "MVPs". You guys seem desperate not to have unanswered questions on forums but MS and the "MVPs" never can answer them. So I'll make you all happy and mark my own response as the answer.
Sheesh...
I understand the frustration. That's actually why I'm pushing on threads like this. We need to find out who knows the answers and where they are. We should not ignore important questions like this. I'm sorry for the poor experience, but we're glad you found the solution.Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)