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

Identical binaries from same source code

P: n/a
I have to homologate my binaries so I need them to be byte-per-byte
identical after each compilation (if the source code is the same,
logically). Does anybody know how to achieve that with either compiler
options or modifying some parts of the binaries?
After some research I've succesfully patched:
- timestamp: in 0x88 address, I have set to zero.
- GUID after <PrivateImplementationDetails>: find this text in file
and set GUID to zero.
but there is an unknown data block after what I supose to be the
strings declarations and I don't know what to do with. In some cases,
setting it to 0's works but in other application hangs. I cannot find
a generic way to clean it.
I need to do that automatically for generic binaries of .NET.

Thanks in advance.
Mar 12 '08 #1
Share this Question
Share on Google+
5 Replies

P: n/a
Hi, I belong to the same development group that tararot2.

Our software must be homolagated by an external company because of
some legislation of our business sector.
The aplicattions we make go to an specific hardware.
The homologation company compiles our code, build the binaries and
homolagates a "crc" of the result.
At this point we could use this binaries that they compiled to be
distributed to this specific hardware but the problems comes in the
future. If a customer report a minor error we have to be able to fix
it, build the binaries, send the result to our customer and after that
send the code to homologate again. The binaries the homolagation
builds must be the same that what we send to our customer.

Now we're trying to achive our goal using mono-cecil.

Thanks in advance
Mar 13 '08 #2

P: n/a
You are right but if there is a bug and I can generate always the
sames binaries, I can fix it and send the binary to my customer in
only one day. If I fix the error, send it to homologate and wait until
the homologation company builds the binary, my customer don't get a
fast support from me. Homologation can be very slow.

It's "just" a question of time. Very important for us and our
Mar 13 '08 #3

P: n/a
Right. In that case, I don't think the question as originally asked
would actually help you. It doesn't help for you to be able to rebuild
the same source to the same binaries multiple times if the homologating
company then uses a different mechanism to compile your code.
This is not a problem. We provide the compiler and method of
compilation to the homologation company. They first validate the
method of compilation.
Now, three questions arise:

1) If you send the same source to the homologating company twice, do
*they* end up with the same binaries?
2) Are they happy to share their homologation methods with you?
1 and 2 -Yes, because of my prior explanation.
3) If you can produce the same binary as the homologation company,
doesn't that defeat the purpose of the legislation? I would expect the
point to be similar to crypto-signing - e.g. to guarantee that the
homologation company has the original source code.
No, because we must explain what we have post changed in the binary
and they validate the method. The don't have to believe in what we
say, they can check the method.

I'm sure this is the way we must do things. The problem is that this
is our first project with C#. Before, with C++ we only had to clear
the timestamp of the binary.
Thanks for your time.
Mar 13 '08 #4

P: n/a
On 13 mar, 15:36, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
Legislation of business sector probably means this is an electronic voting
machine, although there could be similar requirements in other markets.
It's not for a voting system. It's a multiplayer casino-like game
Mar 13 '08 #5

P: n/a
Ok, all clear now.

Thank you very much Jon.
Mar 13 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.