md5 hash einer Datei Lazarus

[1234567890987654321]

Hallo.

Hat jmd. einen Code-Schnipsel, der mir aus einer Datei einen Hash-Wert generiert.
Ich habe es schon mit der Md5-Unit probiert, aber da kam immer ein falscher Hash raus. (MD5Print(MD5String('test.exe'));).

Wenn ich die test.exe zu http://www.fileformat.info/tool/hash.htm hochlade, gibt dieses ein ganz anderen Hash aus.

Wie ermittle ich nun den richtigen Hash?

Danke fürs lesen :-)

[himitsu]

MD5String berechnet von dem übergebenem String den Hash ... die Funktion heißt nicht umsonst MD5String. :wink:
Du brauchst also eine VVariante, welche von einem Buffer, Stream oder direkt von der Datei liest.

Zitat:

Ich habe es schon mit der Md5-Unit probiert

Toll, von solchen Units gibt es tausende...
Mit welcher also?

PS: Über die Forensuche sollte sich eigentlich was finden lassen.

[Luckie]

Und etwas Code, wir du die Unit angewandt hast, wäre ganz gut.

[marcoX]

Ich mutiere heute wohl zu deinem Helfer ;)

http://www.cityinthesky.co.uk/opensource/dcpcrypt

Das Package für Delphi 6 mit dem Assistenten in ein Lazarus-Package umwandeln und DCPReg als "Registriere Unit" anklicken. Fertig! Beispiele liefert der Autor genug mit

[CCRDude]

Dafür braucht's kein DCrypt. Die Unit MD5, die mit Lazarus (oder direkt FPC?) kommt, hat ja alles. Nur muss man halt MD5File() statt MD5String aufrufen :)

[marcoX]

Zitat:

Zitat von CCRDude (Beitrag 1113744)

Dafür braucht's kein DCrypt. Die Unit MD5, die mit Lazarus (oder direkt FPC?) kommt, hat ja alles. Nur muss man halt MD5File() statt MD5String aufrufen :)

Brauchts sicher nicht. Aber Dcrypt ist sehr praktisch und kann neben MD5 noch eine Menge weitere Hashes ;)

[himitsu]

Unter Windows nutze ich für meine wenigen Hashs direkt die WinAPIs für MD5 (wird vorallem für GUIDs verwendet) und SHA1
und eine eigene winzige Implementation für CRC32 ... mehr braucht man doch selten.

[Luckie]

Zitat:

Zitat von himitsu (Beitrag 1113891)

die WinAPIs für MD5 (wird vorallem für GUIDs verwendet) und SHA1

Welche wären das?

[jaenicke]

Das ist in der Cryptography API drin:
http://msdn.microsoft.com/en-us/library/aa380255.aspx

CryptAquireContext + CryptCreateHash mit CALG_MD5 sollten genügen. Die Funktionen gibt es auch noch einmal mit CP statt Crypt, auf dem Handy kann ich grad schlecht den Unterschied sehen.

[CCRDude]

@himitsu/jaenicke: aber gerade jemand, der dick und fett darauf hinweist, daß er Lazarus verwendet, hält eventuell platformübergreifenden Code für sinnvoller ;)

@marcoX: natürlich kann man alles einbauen, was irgendwie praktisch ist. Nur: was bringt es konkret? Geschwindigkeit ist das einzige, was mir da einfällt. Da ist DCrypt deutlich schneller als die MD5.pas von FPC (zumindest in Delphi getestest :oops: ). Aber: solange is sich nicht um sehr große Dateien handelt, ist DEC nochmal um den Faktor zwei schneller als DCrypt. Zumindest in meinen Tests.

Solange es nicht um wirklich große Datenmengen geht, würde ich ein Projekt nicht mit zusätzlichen Abhängigkeiten verkomplizieren.

[himitsu]

Klar, wenn MD5 schon in der Lazarus-CL drin ist, isses natürlich nicht schlecht.

Code, welcher in Lazarus und Delphi laufen soll, aber für Windows geschroeben wurde, könnte natürlich die WinAPI nutzen (in Delphi hat man versäumt MD5 und Co. zu integrieren)
http://www.delphipraxis.net/151812-mini-sha1.html (sind eigentlich nur je 3 kleine APIs, also das Selbe nochmal für MD5)

und ansonsten müßte man wohl seinem Lazarus+Delphi-Code eine systemunabhängige Implementation direkt mitgeben, damit man es dann überall und für alles kompilieren könnte.
Ich programmiere halt nur für Windows und da kann ich uch getrost die WinAPI ausnutzen ... dafür isses ja schließlich da. :angle:

[CCRDude]

Hmmm... das hat mich doch jetzt nicht losgelassen, daher habe ich mal angefangen zu testen...

Vorab: der CryptAcquireContext-Part ist sauteuer. Wer nur einen Hash braucht, sollte eine andere Methode verwenden; wer mehrere Hashes braucht, sollte den Provider nur einmal darüber acquirieren (ich habe das in den initialization/finalization-Teil der Test-Unit dafür gepackt).

Meine Ergebnisse folgen, und obwohl ich bisher nur kurze und mittlere RawByteString untersucht habe und gar nicht auf Dateien gegangen bin, sieht man schon unterschiedliche Ergebnisse für unterschiedliche Anwendungsfälle.

WinCrypt ist bei größeren Datenmengen tatsächlich sehr gut, bei sehr kleinen dagegen das genaue Gegenteil. DEC ist das Gegenteil zu WinCrypt - bei kleinen Mengen um Längen besser, bei großen langsamer. advapi32.dll schlägt sich ebenfalls sehr gut (Windows-intern evtl. gar dasselbe wie WinCrypt?). Der FPC-Code bleibt zurück, ist aber in einer ähnlichen Kategorie wie DCrypt.

Meine Konsequenz? Danke für die Anregungen hier, ich werde den Test mal auf diverse Dateien ausweiten (sowohl per Stream als auch File Mapping) und daraus sicherlich etwas gewinnen :)

Code:

= MD5 (Message Digest 5) =
== String tests ==
=== String test "short text" ===
Test line:    Hallo Welt, Hello World!
Test length:  24
Repeat count: 500000

           RFC 1321 by Matthias Fichtner: 00:01.559 (93421b70ad52f2495be431fa727179c1)
            Free Pascal development team: 00:01.214 (93421b70ad52f2495be431fa727179c1)
                      Windows (WinCrypt): 00:02.565 (93421b70ad52f2495be431fa727179c1)
                Hagen Reddmann (DEC 5.2): 00:00.490 (93421b70ad52f2495be431fa727179c1)
            DCPcrypt v2.0 (David Barton): 00:01.221 (93421b70ad52f2495be431fa727179c1)

=== String test "random long text" ===
Test line:    (0*!!!4%(0)(1(5 2 "$($&*+32()' ',07 4...
Test length:  99999
Repeat count: 1000

           RFC 1321 by Matthias Fichtner: 00:02.317 (db60c7fab72be4c6887b6160df41e45f)
            Free Pascal development team: 00:01.326 (db60c7fab72be4c6887b6160df41e45f)
                      Windows (WinCrypt): 00:00.215 (db60c7fab72be4c6887b6160df41e45f)
                Hagen Reddmann (DEC 5.2): 00:00.180 (db60c7fab72be4c6887b6160df41e45f)
            DCPcrypt v2.0 (David Barton): 00:00.986 (db60c7fab72be4c6887b6160df41e45f)

= SHA-1 (Secure Hash Algorithm 1) =
== String tests ==
=== String test "short text" ===
Test line:    Hallo Welt, Hello World!
Test length:  24
Repeat count: 500000

                             Dave Barton: 00:01.602 (017c54b20080d80e03b1b80ecbdf68a86665e644)
                  Windows (advapi32.dll): 00:00.877 (017c54b20080d80e03b1b80ecbdf68a86665e644)
                      Windows (WinCrypt): 00:02.253 (017c54b20080d80e03b1b80ecbdf68a86665e644)
                Hagen Reddmann (DEC 5.2): 00:00.792 (017c54b20080d80e03b1b80ecbdf68a86665e644)
            DCPcrypt v2.0 (David Barton): 00:01.621 (017c54b20080d80e03b1b80ecbdf68a86665e644)

=== String test "random long text" ===
Test line:    2621%1-+,2(*,*#2*+/0#*/2(*0,'+0%#2%+"...
Test length:  99999
Repeat count: 1000

                             Dave Barton: 00:02.602 (28f429f7e4ab4e631ac5cad469ce8d6056336015)
                  Windows (advapi32.dll): 00:00.264 (28f429f7e4ab4e631ac5cad469ce8d6056336015)
                      Windows (WinCrypt): 00:00.260 (28f429f7e4ab4e631ac5cad469ce8d6056336015)
                Hagen Reddmann (DEC 5.2): 00:00.972 (28f429f7e4ab4e631ac5cad469ce8d6056336015)
            DCPcrypt v2.0 (David Barton): 00:01.638 (28f429f7e4ab4e631ac5cad469ce8d6056336015)

[1234567890987654321]

@CCRDude, kannst du mir mal deinen Quellcode schicken?
Besonderes der zu WinCrypt würde mich sehr interresieren!

[CCRDude]

Ich habe meinen ersten Ansatz mal angehhängt. Benötigt JwaWinCrypt (Jwa wird doch auch von Lazarus installiert, oder?) und irgendwas, um den Hash vom Binärformat in etwas lesbares zu übertragen, daher das snlNumbers, kannst Du sicher austauschen. Geht ja auch mehr um die Idee, wie man damit eine Datei hasht, kannst Du ja in md5.pp abkupfern (neben BlockRead/BlockWrite gibt's noch mindestens zwei weitere Varianten, file streams und file mappings... viel Spaß beim Probieren :) )

[Gargoyl]

Kurz Google gefragt und da kam das: http://www.hackchina.com/en/r/117772/Unit1.pas__html
Da kannst du den Delphi Code einfach "klauen" um MD5 zu berechnen, und hast auch gleich ein Beispiel.
EDIT: hier http://www.hackchina.com/en/cont/117772 gibt es das ganze Projekt.

[CCRDude]

@Gargoyl: mal abgesehen davon, daß sicher niemand klauen will - dieser japanische Code ist von der Implementierung von Matthias Fichtner geklaut, lediglich der Header ist rausgeschnitten.

Der ist nicht nur schlechter als die FPC-Implementierung, die der Threadersteller ja bereits hat, sondern verwendet zudem noch ein FileMapping "am Stück", das bei Dateien ab ca. 2 GB keine Hashes mehr ausspuckt, da die Datei komplett in den Speicher gemappt wird. Aber selbst wenn man dan anpasst und in passenden Stücken mappt, handelt es sich um die langsamste Implementierung.

[himitsu]

Du wirst nichtmal die 2 GB voll in den Speicher bekommen, da man dafür einen zusammenhängenden Speicherbereich benötigt.
Und bei stantardmäßig nur 2 GB virtuellem Speicher, wird es schon schwer werden überhaupt noch 1 GB reinzubekommen.

PS: Bei Dateien über 100-200 maximal 500 MB würde ich sowieso keine MMF verwenden, denn solche Daten auch noch durch die WindowsFileCache zu scheuchen ist nicht grade optimal,
abgesehn davon daß es das system schnell mal ausbremmst, wenn man mehr Daten in die Cache laden will, als aktuell als physischer RAM frei sind (inkl. anderer gecachter Nurlesedaten).
Wird die Cache dann vergrößert, wird schnell mal Programmcode ausgelagert, wellcher dann wieder zurückgeladen werden muß (bremst also das System extrem aus) und/oder es werden andere zu speichernde Daten aus der Cache geschmissen, welche beim Speichern auch bremsend wirken (besonders schlimm, wenn sie danach nochmal verändert und eventuell zurückgeladen werden müßten).
Hier kommt man mit NonCached-Leseoperationen also besser, denn wenn die Daten eh nur einmal sequentiell gelesen werden, macht soeine Cache absolut keinen Sinn.

PS: Wir haben übrigens auch mehrere MD5-Quellcodes in der DP rumliegen.