AutoHotkey Community

FileMD5()

Computes and returns MD5 hash [ RFC1321 Specification ] for a File passed as parameter, with speeds comparable to Hashes.DLL.
You may refer MSDN for Message Digest API

Parameters:

sFile : The fullpath of filename to hash
cSz : *Chunk size factor. Values accepted are 0 thru 8. Default value is 4

Edit 2009-06-18 :

• An important bug fixed: Changed VarSetCapacity( MD5_CTX,24,0 ) to VarSetCapacity( MD5_CTX,128,0 )
• Corrected again to VarSetCapacity( MD5_CTX,104,0). Thanks to Laszlo.

MD5()

Computes and returns MD5 hash [ RFC1321 Specification ] for memory variable contents.

Cool MD5 functions!

AutoHotkey Doesn't have an md5 function on rosetta code yet:
http://www.rosettacode.org/wiki/Tasks_not_implemented_in_AutoHotkey

You (or somebody) should post on Rosetta Code's MD5 page: http://www.rosettacode.org/wiki/MD5

Thanks!

_________________
Scripts - License

Nice! I guess the right size is VarSetCapacity(MD5_CTX,104), though. Anything larger works, too. The string version at the second dll call needs VarSetCapacity(V) at the end of the line, not VarSetCapacity(L).

Also, the right offset to read the digest from is 87+A_Index. 7+A_Index works, too, but it is not the intended place.

It is not a fair rosettacode solution, because the work is done in the Windows advapi32.dll, not in AHK. I am not even sure if machine code functions qualify, because they are processor dependent, not in the control of AHK.

Thanks!




I do not understand that struct at all!.. I vaguely picked that number from here



I agree Sir. Maybe you can consider posting your native implementation of MD5()

MSDN says:It is 2*4+4*4+64+16 = 104 bytes. The offset for the result (digest) is 88.

oops. I didn't know you had already done that, Laszlo. I agree with SKAN, you should post yours on rosetta code.

_________________
Scripts - License

Thank you Sir.





I did not view that far with my Binspector. Seeing that the digest is also available at offset 8, I happily contended with 24 until I noticed I am not getting proper results for small strings.

Thanks again for the clarification..

Edit: I have updated the code with right VarSetCapacity and corrected the Message offset to read from.

Hi SKAN, many thanks for the MD5() function.

I'm curious. I notice that if you omit the second argument, it calculates the length on it's own. Why would you ever want to include the second argument? And why does the function use VarSetCapacity to calculate the capacity rather than just using StrLen?

Second question first:



StrLen() will not return the correct length for binary data which contain null(s).





VarSetCapacity() will not be reliable, when a variable is assigned with := operator.
In those cases, it is best to use StrLen( Data ) as second parameter.

That's very interesting and a bit disturbing. Is VarSetCapacity wrong in those cases because it is telling the capacity of the variable rather than the length of the string that has been assigned to it? I may have already found a case in which not using StrLen leads to an incorrect hash.

I'm only going to be using it for relatively short strings that were generated within AHK, so I presume that these won't have any Nulls. I'd like to remove the second parameter, just using StrLen instead. To allow for calling the function on a constant string (rather than a variable), I'd also like to remove the "byref." Do you know if the following would be safe and reliable? Idon't know if it matters, but I will be using both Unicode and Ascii builds

Thanks again for the prompt help...

Then the function would work on the copy of original string. Redundant!



As is, the function would return incorrect results on AHK_L.. I need some time to test it. I will revert at earliest.

It may be redundant, but ByRef isn't necessarily more efficient. In one case you have a one-time string copy when the function is called, and in the other case every access to the variable has an extra level of indirection, i.e. V -> variable passed by caller. I'd generally recommend using ByRef only when required for the function to work. For instance, ByRef would be required to support hashing binary data. For usability, you could do something like this:
The extra function call is minimal overhead. However, for very large strings ByRef will perform better -- I guess in such cases the string would generally be in a variable already. Rather than having the extra function, JoeSchmoe can do this:

Looks like you only need to convert the string length to bytes; i.e. multiply by (A_IsUnicode ? 2:1). VarSetCapacity already returns a value in bytes.

Maybe I am missing something obvious, but I am not able to produce correct results ( AHK_L ) without calling WideCharToMultiByte() prior to MD5Update()

@JoeSchmoe

Okay! .. I got it:




You may compare results with http://md5-hash-online.waraxe.us/

Thanks, SKAN! This looks perfect. I can't wait to try it out in the code tomorrow.