|
Most likely they are different due to changes in the assembly metadata, like the file version and/or assembly version. How are you determining the files are not the same?
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
I used HexEdit to compare the files. In one case the difference was from:
{231F082C-31A4-4DF7-A34E-9B7383E240FD}
to:
{20EFE830-6E58-4A20-B725-F263FA47C142}
which looks like a regenerated version but in other cases the differences were just a few "random" bytes.
My customer expects to being able to confirm a certain set of files was used to create a executable by comparing the executable created at another time. Is there another way to confirm this?
|
|
|
|
|
As Luc said, it really isn't possible to do a binary comparison on a file and tell what changed about them. The best you can hope for is that you can tell the file didn't change.
The only way to recompile and have the resulting binary be the same is to ensure that absolutely nothing in the source code changes, including things like version stamps, etc.
It isn't clear what your customers real expectation is and why they want this ability. A good source control system and build process will ensure that you can recreate an executable from the same source each time.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
My customer has a medical device background (safety critical, high process) and I must PROVE the build process, especially when re-created on another machine, results in the same executable. Unfortunately, have good process isn't enough.
|
|
|
|
|
Hmmm...for the most part having a repeatable process has to be good enough. That is the basis for CMM certifications. Would computing a CRC or some other type of checksum on the files and comparing that checksum be enough?
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Considering there are plenty of situations where COM-exposed GUID are generated on every compile, and never the same between compiles, and between machines, you can't compare the two and come up with the exact same binary.
|
|
|
|
|
Hi,
IMO this is impossible:
- first, pretending to know at what locations EXE files could differ even when all the sources are the same is assuming a lot, e.g. is it documented the compiler must allocate objects in a specific order? is it documented the linker will always link things in the same order?
- second, assume you have the magic tool; I build once from some sources; I build again from the same sources (tool says: same source); now I replace one of the source files by a copy, modifying some comments, the name of a local variable, the order of two declaration statements, etc
and build again; the tool will tell you once more the sources were the same although they were not.
Luc Pattyn [Forum Guidelines] [My Articles]
I use ListBoxes for line-oriented text (not TextBoxes), and PictureBoxes for pictures (not drawings).
modified on Friday, June 10, 2011 12:25 PM
|
|
|
|
|
It's fairly common, at least in the embedded development world, to compare "executables" in this manner, however the "executable" is a binary image that is loaded into a chip.
I didn't intend a file name comparison of the sources. I was hoping there was another way to insure two executables are from exactly the same source code/included libraries/etc.
|
|
|
|
|
Hi,
cwster wrote: It's fairly common, at least in the embedded development world, to compare "executables" in this manner,
I am aware of that, however the original question seemed very general; under controlled circumstances
(same PC, same tools, same settings, etc, the only possible difference is in one or more source files) one can do much better obviously.
On the other hand, COFF/IntelHex/whatever you use to download code would be much simpler than the
Windows Portable Executable file format.
But anyway, I can always come up with a different source that results in an "exe" that is so similar that no tool in the world will be able to tell whether the original source file was used or not.
(comments, local var names, declaration order, etc etc).
Suggestion: calculate checksums for each source file (use a separate tool that runs before building
the "exe", and somehow add a DATA section that gets to contain those checksums (this is not hard
when another little tool creates a new source file from all the checksums, possibly using
assembly code or linker commands).
Alternative: you could replace checksums by embedded version numbers, if you would trust those.
That would require e.g. an editor that always increments the version number automatically.
Luc Pattyn [Forum Guidelines] [My Articles]
I use ListBoxes for line-oriented text (not TextBoxes), and PictureBoxes for pictures (not drawings).
modified on Friday, June 10, 2011 12:26 PM
|
|
|
|
|
You have to sign the assembly.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Signing the assembly will only show that it came from the same company, not the same source code. A CRC check might work, however.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
If you mean a CRC of the source code that wouldn't cover all the code linked in, etc.
If you mean a CRC of the exe, those I know to be different.
Did I miss your point?
|
|
|
|
|
Nope you didn't miss the point. I think I did. Disregard...
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
As others already said, it's impossible, because compiler and linker might behave differently each run.
What you could do is compile the executable with exactly the same compilation options (optimization level etc.) and tell from a diff of the IL code that nothing has changed in such a manner that it might influence the original flow of the program.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Hi,
maybe you are asking the wrong question. If you want to relate an executable to other things such as source files, you could:
1.
either check in the executable itself, and provide dependencies as appropriate.
2.
or simply create a container that holds all requirements, analysis files, design files, sources, scripts, executables, data files, documentation, release notes, ... and everything that belongs to the same generation. I tend to use ZIP a lot for exactly that purpose: making snapshots in between releases,
and at release points. Disk space is cheap nowadays!
Luc Pattyn [Forum Guidelines] [My Articles]
I use ListBoxes for line-oriented text (not TextBoxes), and PictureBoxes for pictures (not drawings).
modified on Friday, June 10, 2011 12:26 PM
|
|
|
|
|
Luc Pattyn wrote: Disk space is cheap nowadays!
Now you tell me!
|
|
|
|
|
It's hard to do a binary comparison, as you'd have to understand the file format (PE/COFF/.NET Metadata/etc.) to know where where things like timestamps/GUIDs are stored.
However, since the files are C# .exe's, maybe you could disassemble them using ILDASM.exe and compare the resulting .IL files?
Try comparing the .IL of a few different compiles of the same source.
Hopefully the order of methods etc. won't change (same source, same compiler version, same ILDASM version => shouldn't change unless it depends on a timestamp or generated GUID).
And if you see changing version numbers or GUIDs in the IL output, they're much easier to filter out in the text version than in the binary version.
|
|
|
|
|
The only way I can think of to accomplish this is to make one executable a copy of the other.
Zip everything up onto some kind of storage and lock that away in a dual key safe, or whatever. Then when a new exe is required for whatever reason, client turns up with his key, you turn up with yours and some sort of copying device appropriate to the storage medium chosen. Make copy of exe, lock rest away. Viola!
Cannot see any other way to do it.
Henry Minute
If you open a can of worms, any viable solution *MUST* involve a larger can.
|
|
|
|
|
my app can have multiple icons through win32 res but the problem is that it do not support alpha. Is there anyway other way ?
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
Hi there
I have written an application that attempts to transfer a file using the Socket class. I am able to set up the command socket and the data socket just fine, and transfer *most* of the file. The problem is that the file size on the server after being transferred is smaller than the number of bytes my software says it transferred. If I use a third-party FTP product, such as Core FTP, to download the file I just uploaded, the file is still too short by less than the length of my transfer buffer.
My upload code is:
// Get a separate socket for the data transfer
Socket dataSocket = GetDataSocket(cmdSocket);
// Start uploading!
int numBytesRead = 0;
byte[] byteBuffer = new byte[TRANSFER_BUFFER_SIZE];
int m_BytesTransferred = 0;
while ((numBytesRead = fs.Read(byteBuffer, 0, TRANSFER_BUFFER_SIZE)) > 0 && !m_Cancel)
{
try
{
dataSocket.Send(byteBuffer, numBytesRead, SocketFlags.None);
m_BytesTransferred += (long)numBytesRead;
// This is to let my UI update the progress meter
Thread.Sleep(20);
}
catch (SocketException ex)
{
break;
}
}
// Finished with the file, so close it.
fs.Close();
if (dataSocket.Connected)
{
Thread.Sleep(500);
dataSocket.Shutdown(SocketShutdown.Both);
dataSocket.Close();
}
My download code is:
Socket dataSocket = GetDataSocket(cmdSocket);
string retString = "";
m_BytesTransferred = 0;
// Set the time when we will give up on the transfer
DateTime endTime = DateTime.Now.AddSeconds(5.0);
int numBytesRecd = 0;
byte[] transferBuffer = new byte[TRANSFER_BUFFER_SIZE];
while (endTime > DateTime.Now && !m_Cancel)
{
numBytesRecd = dataSocket.Receive(transferBuffer, TRANSFER_BUFFER_SIZE, SocketFlags.None);
if (numBytesRecd <= 0)
{
break;
}
fs.Write(transferBuffer, 0, numBytesRecd);
m_BytesTransferred += (long)numBytesRecd;
// Reset the time when we will give up if we just received some bytes
endTime = DateTime.Now.AddSeconds(10.0);
Thread.Sleep(20);
}
// All done writing to the file
fs.Close();
if (dataSocket.Connected)
{
dataSocket.Close();
}
I have verified that the portion of the file that has been transferred is the same as the original file. I have even put in a Thread.Sleep(500) to wait for the last buffer to transfer before calling Socket.Shutdown() and Socket.Close(). Nothing has worked. Any suggestions?
|
|
|
|
|
I'm not sure where you're losing data, but you can greatly simplify your code
by implementing a simple protocol - the simplest being send a header first that
indicates how many bytes of data will follow. This header could be a simple integer.
Member 3216808 wrote: I have even put in a Thread.Sleep(500) to wait for the last buffer to transfer
You shouldn't need to use Sleep() anywhere, and using it like that is really bad.
Even if it was accurate, what if it took 501ms? You can't possibly throw meaningless
millisecond values at it and hope something works. You're also definitely not guaranteed
20ms accuracy on Sleep()...
Other than that, I can't tell what's up - your code doesn't look like it has anything to do with
FTP - at least not the standard FTP. You haven't indicated what socket protocol you're using, whether
you're using blocking/non-blocking sockets, etc...
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
This is how I get my data socket:
dataSocket = new Socket(endPoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
I send data on the socket after sending a STOR command on the command socket; at least, that is what I call the socket where text is sent and received. When the data transfer is "complete," I get an appropriate text message on the command socket saying that the transfer completed, and giving info on how long the transfer took.
This is my first time using sockets, so I am not sure what else you are asking. I used the Thread.Sleep() in desperation when I realized that some data was disappearing somewhere. The Thread.Sleep(20) is just so the thread will yield and let other things happen in the UI - the exact timing is unimportant.
I am not sure that adding a header would be too useful - I would be able to detect that data had disappeared, but I would have no way to correct the problem.
|
|
|
|
|
Hi,
I there any special reason to use socket?? , i am just asking this question because in .net there are better way of transferring data using ftp , one of those method is to use 'FtpWebRequest' class , which is inbuilt in .net (under the namespace System.Net), following is the code you may use to send a file to an FTP server
using System;
using System.IO;
using System.Net;
using System.Text;
namespace Examples.System.Net
{
public class WebRequestGetExample
{
public static void Main ()
{
FtpWebRequest request = (FtpWebRequest)WebRequest.Create("ftp://www.yourFtpLocation.com");
request.Method = WebRequestMethods.Ftp.UploadFile;
request.Credentials = new NetworkCredential ("username","Password");
StreamReader sourceStream = new StreamReader("FileYouWantToUpload.txt");
byte [] fileContents = Encoding.UTF8.GetBytes(sourceStream.ReadToEnd());
sourceStream.Close();
request.ContentLength = fileContents.Length;
Stream requestStream = request.GetRequestStream();
requestStream.Write(fileContents, 0, fileContents.Length);
requestStream.Close();
FtpWebResponse response = (FtpWebResponse)request.GetResponse();
Console.WriteLine("Upload File Complete, status {0}", response.StatusDescription);
response.Close();
}
}
}
}
I hope this helps
-Regards
Bharat Jain
bharat.jain.nagpur@gmail.com
|
|
|
|
|
Hi everybody,
i have a little problem. I'm writing a console application that send(via socket)a simple string ( "P" ) to a server. If this app connect directly to server, i get a right answer. But this app must connect on a proxy(Linux Squid) to contact my server.
How can i route, my socket string, via proxy?
Thanks.
modified on Wednesday, January 14, 2009 10:12 AM
|
|
|
|
|
Hi ,
I think that is not something we can do through our application , that can be done through the setting on the proxy , on the proxy you need to froward the port you are using , if this forwarding is blocked you will not be able to connect to the server.
I am not 100% sure as i have never tried , but this is the first thought that came to my mind.
-Regards
Bharat Jain
bharat.jain.nagpur@gmail.com
|
|
|
|
|