Hi guys,
i am using the MD5 routines put together by RudeBoy, but the
problem is i am getting a different checksum every time i submit
the same file. I have included the essentials of the code below,
but here is a brief overview:

- i set up a 16 byte array buffer in VB
- i call the MD5Translate function with a filename and that buffer
- i jump to another function which does opens the file, does a HeapAlloc, then reads the file into memory
- returning to MD5Translate, i have the pointer to the buffer containing the file, and the length of the file
- i round the length of the file up to the next 64 byte multiple (related to my question yesterday)
- i then launch into the checksum calculation (which is the original source)

I have logged the steps through the dll, the file is being loaded
correctly, the same number of bytes are always read in from the
file. The only thing that changes from run to run is the position in
memory of the file buffer (i don't do a HeapFree yet, memory leak,
naughty me :) ) I am also happy with the passing of parameters
from VB to asm, there is no problem there (i get the same result
whether i use a byte array or a fixed length string).

Here is the relevant code (error handling and debug macros
stripped out). My changes are in red. Thanks for any tips :)



MD5Translate proc uses edi esi edx ecx ebx lpData:DWORD, MD5Ptr:DWORD

LOCAL iLen :DWORD
LOCAL a:DWORD, b:DWORD
LOCAL _c:DWORD, d:DWORD
LOCAL x[16 * sizeof(DWORD)]:DWORD
[color=red]
invoke loadFile, lpData
mov lpData, eax
ialign ecx, 64 ;round length up to next 64 byte multiple
mov iLen, ecx

invoke MDxInit, MD5Ptr
[/color]
assume esi:ptr MD5Sum
lea edi, table
mov esi, MD5Ptr

MD5Again:
lea eax, x
invoke _CopyMemory, eax, lpData, 64
add lpData, 64
...etc...
...this is just the rest of the algo, unchanged...

--------------------------------------
[color=red]
loadFile proc lpFileName :DWORD

LOCAL hFile :DWORD
LOCAL hHeap :DWORD
LOCAL dwNumBytesRead :DWORD
LOCAL dwFileSize :DWORD

mov dwNumBytesRead, 0

invoke CreateFile, lpFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL
mov hFile, eax

invoke GetFileSize, hFile, NULL
mov dwFileSize, eax

invoke GetProcessHeap
mov hHeap, eax

invoke HeapAlloc, hHeap, HEAP_ZERO_MEMORY, dwFileSize

lea edi, dwNumBytesRead
invoke ReadFile, hFile, eax, dwFileSize, edi, NULL
.IF eax
;pass pointer to file data and length of data back:
;--------------------------------------------------
mov eax, hHeap
mov ecx, dwFileSize

ret
.ENDIF

;ReadFile failed:
;----------------
mov eax, 0
ret
loadFile endp
[/color]
--------------------------------------

MDxInit proc uses esi MD5Ptr:DWORD
assume esi:ptr MD5Sum
mov esi, MD5Ptr
mov eax, 067452301h
mov [esi].dwSum1, eax
mov eax, 0efcdab89h
mov [esi].dwSum2, eax
mov eax, 098badcfeh
mov [esi].dwSum3, eax
mov eax, 010325476h
mov [esi].dwSum4, eax
ret
MDxInit endp


these are some of the checksums i got from running the same file through the process several times:
B9C39B107E6E5F08DC24FB148D263749
53A1E13A80199644C67C0147D3EBA83B
F96B3FFC7BE730DACAE2F5CEFD0C90E9
E241DF6FC4AC42D81E7141FDE3083A49
A2308DA4AC3FC5ED914BD41B404A5E16
Posted on 2002-04-16 18:03:44 by sluggy
Yep, i have logged everything up until where the actual algo starts, and everything is the same each time i run that file through. Could it be a data alignment problem? Or am i doing something screwy with the length of the data?

I have attached the source if you need to see the complete algorithm, look for the MD5Translate function.
Posted on 2002-04-16 18:33:51 by sluggy
Hmmm, Opera seems to have a problem attaching files..... here it is.
Posted on 2002-04-16 18:36:15 by sluggy
Woot!! Done it! The problem was the padding of the file, i was trying to do it manually, but there happened to be a function in the source to do it. So after studying the one sample bit of C code, i was able to do things properly, finally.

A lesson to others: when you release code as freeware/open source, make sure you either document it, or put heaps of comments in it......
Posted on 2002-04-16 21:36:28 by sluggy
Here is optimized MD5 hope it helps.
Posted on 2002-04-17 07:33:04 by LaptoniC
Thanks for that LaptoniC, i will have a serious look at it in the next couple of days. RudeBoy's code is really fast, a lot faster than what i expected it to be (this expectation was based on using other 3rd party md5'ers). I will also run some timing tests on the code you posted, i am interested in what the results will be :)
Posted on 2002-04-17 17:38:43 by sluggy
it comes with a test app in /test

the test app is a console app, just supply it with a filename.

for the rest look inthe radasm project it's all pretty clear :)

Thx go to The Rudeboy

edit: it's a hashroutine for files but it can easily be reworked to use just data :)
Posted on 2002-04-17 18:53:30 by Hiroshimator
Might as well add the functionality from a data block in memory :)

I added a seperate little test file that loads a file in memory (full so don't go using it on 2G files ;) ) and performs the test as well.


so download this again :) (sorry for your troubles)
Posted on 2002-04-17 19:36:46 by Hiroshimator