Two compiled files have different hash sums

[AZJIO]

I compiled two files a few seconds apart and am getting different files. I assumed that the date was saved in the file, but it turned out that the difference was in dots and other random characters.

Code for comparing executable files:

Code: Select all

MessageRequester("","")

Output of position and data in which there is a difference

Code: Select all

EnableExplicit

Global bytes
 
Procedure OpenFileToGadget(FilePath$)
    Protected length, oFile, *mem
    oFile = ReadFile(#PB_Any, FilePath$)
    If oFile
        length = Lof(oFile)
        *mem = AllocateMemory(length)
        If *mem
            bytes = ReadData(oFile, *mem, length)
            If bytes
               ProcedureReturn *mem
            EndIf
        EndIf
        CloseFile(oFile)
    EndIf
    ProcedureReturn 0
EndProcedure
 
Define *FData1, *FData2
Global length1, length2

Procedure CompareData(*b1.Byte, *b2.Byte)
    Protected i, toggle = 0, z
    Protected *c1.Byte, *c2.Byte
    Protected *Compare1, *Compare2

    If length1 <> length2
        ProcedureReturn 0
    EndIf
    
    If length1 = 0 Or length1 = 0
        ProcedureReturn 0
    EndIf
    
    If *b1 = 0 Or *b2 = 0
        ProcedureReturn 0
    EndIf
    
    *Compare1 = AllocateMemory(length1)
    *Compare2 = AllocateMemory(length1)
    If Not (*Compare1 And *Compare2)
        ProcedureReturn 0
    EndIf
    *c1 = *Compare1
    *c2 = *Compare2
    
    For i = 1 To length1
    	z + 1
    	If *b1\b <> *b2\b
    		*c1\b = *b1\b
    		*c2\b = *b2\b
	    	*c1 + 1
	    	*c2 + 1
	    	If toggle
	    		Debug z
	    	EndIf
    		toggle = 0
    	Else
    		toggle = 1
    	EndIf
    	*b1 + 1
    	*b2 + 1
    Next
    ShowMemoryViewer(*Compare2, 1000)
EndProcedure

*FData1 = OpenFileToGadget("C:\1.exe")
length1 = bytes
*FData2 = OpenFileToGadget("C:\2.exe")
length2 = bytes

CompareData(*FData1, *FData2)



FreeMemory(*FData1)
FreeMemory(*FData2)

[NicTheQuick]

Dates can be the reason. And since they are stored in a binary format they may appear as random characters.

It would be a bit easier to follow you if you would just show the differences so we do not need to check that by ourselves. Maybe with an excerpt from a hex viewer Thank you!

[AZJIO]

Code: Select all

§§§§§§§§.......
..............
..............
..............
..............
..............
..............
..............
..............
..............
..............
..............

hex (8 pieces (A7))

Code: Select all

A7 A7 A7 A7 A7 A7 A7 A7 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

positions (8 pieces)

Code: Select all

137
5637
5677
5701
5741
5765
5805
5829

[NicTheQuick]

That looks not like something I would've expected. And I don't have any more ideas here. Sorry.

[benubi]

That will necessarily happen when you have compiled them seconds apart. But I don't know what that unexpected randomness means. These could be counters/constants like the build count or version numbering but these should only be compiled exactly where they are used (correct me if I'm wrong). Did you change compiler options in between?

There's also the possibility of a virus infection but if there are only 8 different short pieces in the executable I think you can mostly exclude that option (except if it's the martian virus from the movie Lifeform/Invader).

[AZJIO]

benubi
1. Why should I change anything if the essence of the test is “change nothing”? The point of the test is to get the same file if you haven't changed anything.
2. My versions are more interesting than yours. My theory is that it could be some kind of separator or placeholder, a memory cell that is not defined as 0 or something else and is intended to put data there and at the time of compilation there was some data in the cell. Similar to AllocateMemory with the #PB_Memory_NoClear flag, you get a piece of memory that was not cleared before you used it, but something is already there. There's no point in wasting time cleaning.
3. The question came from here

[Bitblazer]

Portable executable / PE format

[Tenaja]

There's also an option for an incrementing version code constant, which would change a checksum. It's in the settings... If you've enabled it and forgotten, it could cause this.