32 Zeichen breite Prüfsumme, aber nicht MD5. Was für ein Prüfsummenalgorithmus könnte das noch sein?

Also wer eine Prüfsumme angibt, hat auch den Typ der Prüfsumme anzugeben, denn sonst ist sie ja wohl Wertlos. Sicher das es sich überhaupt um eine Prüfsumme handelt?

Wenn der Autor da irgend einen Quark hinschreibt, kannst Du so viel probieren wie Du willst. Im Endeffekt, kann man sich immer eine Formel zusammenreimen, die dann beweisen soll, dass die Datei der Prüfsumme entspricht, nur wird das nicht stimmen, wenn die Formel, mit der die Prüfsumme erstellt wurde, ganz anders lautet. Der Typ der Prüfsumme ist also ein unverzichtbarer wichtiger weiterer Faktor.

Wo bitte steht denn nun die Prüfsumme oder wie lautet sie? Eine Prüfsumme wird errechnet an der Bitkonstellation, die die Datei darstellt. Es wird nicht einfach eine erstellt, die dann einfach in die Datei geschrieben wird, das würde keinen Sinn machen, es geht bei einer Prüfsumme darum, Merkmale einer Datei so kompakt (aber ebenso auch sicher) wie nur möglich zu beschreiben.

Irrelevant schrieb:

Also wer eine Prüfsumme angibt, hat auch den Typ der Prüfsumme anzugeben, denn sonst ist sie ja wohl Wertlos.

Stimme zu.

Sicher das es sich überhaupt um eine Prüfsumme handelt?

Nein, aber es ist recht unüblich daß man so etwas in den Dateinamen vor dem eigentlichen aussagekräftigen Namen schreibt.
Außerdem besteht dieser 32 Zeichen lange String ausschließlich nur aus Ziffern und den Buchstaben a-f, allein das spricht deutlich für eine Prüfsumme.

Die Dateinamen heißen z.B. so:

0c03e296c72834bd72b7175543bbfad7-50427-17_fix.rar
6bcbadbd432d55c5232efa3739e0c6a5-rep_gen.rar
1d7cf9d563597fc8af9aeec9ef11236f-tslrcm17.exe

Sollen das etwa keine Prüfsummen sein, die da am Anfang stehen?

Der Typ der Prüfsumme ist also ein unverzichtbarer wichtiger weiterer Faktor.

Selbstverständlich, deswegen muß man den Typ ja auch rauskriegen.

Wo bitte steht denn nun die Prüfsumme oder wie lautet sie?

Habe ich doch gesagt, im Dateinamen.

Eine Prüfsumme wird errechnet an der Bitkonstellation, die die Datei darstellt. Es wird nicht einfach eine erstellt, die dann einfach in die Datei geschrieben wird, das würde keinen Sinn machen, es geht bei einer Prüfsumme darum, Merkmale einer Datei so kompakt (aber ebenso auch sicher) wie nur möglich zu beschreiben.

Der Dateiname bleibt bei der Prüfsummenbildung unberücksichtigt, deswegen kann man ihn im Prinzip jederzeit ändern und die Prüfsumme an den Dateinamen hängen.
Das könnte der ursprüngliche Autor dieser Datei durchaus gemacht haben.

Kein md5sum schrieb:

Der Dateiname bleibt bei der Prüfsummenbildung unberücksichtigt, deswegen kann man ihn im Prinzip jederzeit ändern und die Prüfsumme an den Dateinamen hängen.
Das könnte der ursprüngliche Autor dieser Datei durchaus gemacht haben.

Siehe auch z.B. dieses Beispiel:

~/test$ echo "blablabla" > test.txt
~/test$ md5sum test.txt 
d1bf8fc6af9166875316587ad697a719  test.txt
~/test$ cp test.txt d1bf8fc6af9166875316587ad697a719-unfug.txt
~/test$ md5sum *.txt
d1bf8fc6af9166875316587ad697a719  d1bf8fc6af9166875316587ad697a719-unfug.txt
d1bf8fc6af9166875316587ad697a719  test.txt
~/test$

Gleiche Datei, unterschiedlicher Dateiname, aber dennoch gleiche Prüfsumme und die steht sogar im Dateinamen, das funktioniert also durchaus.

Unüblich ist es trotzdem, denn normalerweise fügt man eine md5sum.md5 Datei an, die man dann auch leicht mit
md5sum -c md5sum.md5
prüfen kann, aber das hat der Typ halt nicht gemacht.

PS:

hier über diesen Link kriegst du die Datei auch:
http://findfiles.com/list.php?string=1d7cf9d563597fc8af9aeec9ef11236f-tslrcm17.exe&size=33015882&db=Mirrors

Dann kannst du mal selber überprüfen, welcher Prüfsummenalgo das sein könnte.

Oder hier, die kleinere Datei von den 3.
http://www.gamefront.com/files/20306608/Hassat_Hunter___Unofficial_Fix_for_1_7

zwutz

das wird ne simple unique file id sein, keine Prüfsumme.

EXDW

Kein md5sum schrieb:

Die Dateinamen heißen z.B. so:

0c03e296c72834bd72b7175543bbfad7-50427-17_fix.rar
6bcbadbd432d55c5232efa3739e0c6a5-rep_gen.rar
1d7cf9d563597fc8af9aeec9ef11236f-tslrcm17.exe

Das sind keine Prüfsummen, das sind GUIDs wo die "-" einfach weg gelassen wurden.

0c03e296-c728-34bd-72b7-175543bbfad7
6bcbadbd-432d-55c5-232e-fa3739e0c6a5
1d7cf9d5-6359-7fc8-af9a-eec9ef11236f

David W schrieb:

Kein md5sum schrieb:
Die Dateinamen heißen z.B. so:
0c03e296c72834bd72b7175543bbfad7-50427-17_fix.rar
6bcbadbd432d55c5232efa3739e0c6a5-rep_gen.rar
1d7cf9d563597fc8af9aeec9ef11236f-tslrcm17.exe
Das sind keine Prüfsummen, das sind GUIDs wo die "-" einfach weg gelassen wurden.

0c03e296-c728-34bd-72b7-175543bbfad7
6bcbadbd-432d-55c5-232e-fa3739e0c6a5
1d7cf9d5-6359-7fc8-af9a-eec9ef11236f

Ok, das wäre eine plausible Erklärung, aber was macht dich da so sicher?

man rofl, wenn nicht mal der Herausgeber der Datei sagt, dass es eine Prüfsumme ist, dann ist es auch keine! Es sei denn Du bist so sturrköpfig, dass Du dir eine Formel ausdenkst, mit der Du dann sagen kannst, welche Bytes, die aus der Auflösung der Prüfsumme stammen, mit welchen Bytes aus der Datei, identisch sein müssen und auch sind. Wenn auch diese Formel mehr als Unsicher erscheinen wird.

EXDW

Kein md5sum schrieb:

David W schrieb:
Kein md5sum schrieb:
Die Dateinamen heißen z.B. so:
0c03e296c72834bd72b7175543bbfad7-50427-17_fix.rar
6bcbadbd432d55c5232efa3739e0c6a5-rep_gen.rar
1d7cf9d563597fc8af9aeec9ef11236f-tslrcm17.exe
Das sind keine Prüfsummen, das sind GUIDs wo die "-" einfach weg gelassen wurden.

0c03e296-c728-34bd-72b7-175543bbfad7
6bcbadbd-432d-55c5-232e-fa3739e0c6a5
1d7cf9d5-6359-7fc8-af9a-eec9ef11236f
Ok, das wäre eine plausible Erklärung, aber was macht dich da so sicher?

Eine GUID besteht aus den Zahlen 0-9 sowie die Buchstaben A-F und setzt sich aus 8-4-4-4-12 zusammen. Das passt alles.

Bashar

David W schrieb:

Kein md5sum schrieb:
David W schrieb:
Kein md5sum schrieb:
Die Dateinamen heißen z.B. so:
0c03e296c72834bd72b7175543bbfad7-50427-17_fix.rar
6bcbadbd432d55c5232efa3739e0c6a5-rep_gen.rar
1d7cf9d563597fc8af9aeec9ef11236f-tslrcm17.exe
Das sind keine Prüfsummen, das sind GUIDs wo die "-" einfach weg gelassen wurden.

0c03e296-c728-34bd-72b7-175543bbfad7
6bcbadbd-432d-55c5-232e-fa3739e0c6a5
1d7cf9d5-6359-7fc8-af9a-eec9ef11236f
Ok, das wäre eine plausible Erklärung, aber was macht dich da so sicher?
Eine GUID besteht aus den Zahlen 0-9 sowie die Buchstaben A-F und setzt sich aus 8-4-4-4-12 zusammen. Das passt alles.

Die Zusammensetzung weißt du doch gar nicht, die Bindestriche sind von dir selbst eingefügt worden. Ohne das sind es nur 16 Bytes in Hexadezimalschreibweise, das deutet wohl kaum ohne weiteres auf eine GUID hin.

ipsec

Andererseits wurden schon alle möglichen und unmöglichen Hashes durchprobiert, wobei keiner passt. Das lässt schließen, dass entweder der hash falsch ist, oder es sich doch um irgendeine Art UID handelt.

Mann oh mann Wenn Du es so genau wissen willst, wie wäre es dann mal den Herausgeber der Datei zu fragen oder den offiziellen Hoster bzw. das Team oder die Comunity, die die Datei gehostet hat bzw. nach den Kontaktinformationen des Dateiherausgebers?

hustbaer

Das sieht nicht nach GUIDs aus, denn das "Generator-Version" Feld ist ebenfalls Random. Genau so die "Type-Variant" Bits.

Vielleicht sind es einfach gesalzene Hashcodes?

SeppJ

hustbaer schrieb:

Vielleicht sind es einfach gesalzene Hashcodes?

Aber dann würde das Salz fehlen, ohne das es unnütz ist. Außerdem: Warum sollte man Dateihashes salzen? Die Datei ist doch im Klartext mitgeliefert!

Und da die Durchschnittsdatei deutlich länger als der Hash selbst ist, gäbe es auch unzählige Kollisionen, so dass Salz noch viel weniger Sinn macht.

Ich mache mir jetzt eine Pizza mit Bit definierten Käse.

hustbaer

SeppJ schrieb:

hustbaer schrieb:

Vielleicht sind es einfach gesalzene Hashcodes?

Aber dann würde das Salz fehlen, ohne das es unnütz ist.

Das Salz könnte konstant sein, hardcoded im Programm.

Außerdem: Warum sollte man Dateihashes salzen? Die Datei ist doch im Klartext mitgeliefert!

Und da die Durchschnittsdatei deutlich länger als der Hash selbst ist, gäbe es auch unzählige Kollisionen, so dass Salz noch viel weniger Sinn macht.

Weiss nicht. Ich hab' nicht behauptet dass es sinnvoll wäre

Ich hab' schon Programme gesehen wo alles mit z.T. fixen Salt-Strings gesalzen wurde, einfach nur so, damit die Hashcodes keine Standard-MD5/Standard-WasAuchImmer sind.

Es könnte auch ganz was anderes sein. z.B. wie schon vermutet wurde irgendwelche Random IDs (ob man es dann GUID nennt oder nicht is ja egal). Oder der Hashcode irgendeines internen Werts (SCC-Pfad, Ticket-Nummer, ...). Oder ein Hashcode über den Inhalt der Archive (zumindest die beiden .rar sind ja eindeutig Archive). Oder 100 andere Sachen.

Irrelevant schrieb:

Mann oh mann Wenn Du es so genau wissen willst, wie wäre es dann mal den Herausgeber der Datei zu fragen oder den offiziellen Hoster bzw. das Team oder die Comunity, die die Datei gehostet hat bzw. nach den Kontaktinformationen des Dateiherausgebers?

Guten Morgen "Irrelevant"!
http://deadlystream.com/forum/topic/762-what-are-this-32-char-long-checksums-in-the-name-of-the-files-at-the-download-page/page__pid__8266#entry8266

hustbaer schrieb:

Ich hab' schon Programme gesehen wo alles mit z.T. fixen Salt-Strings gesalzen wurde, einfach nur so, damit die Hashcodes keine Standard-MD5/Standard-WasAuchImmer sind.

Wenn es fixe Salt-Strings wären, dann könnte man den Hashcode allerdings durchaus herausbekommen.
Denn man hat ja bereits 3 Dateien mit denen man arbeien kann, von denen kann man alle normale MD5 usw. Hashs erzeugen und dann schauen, was addiert/abgezogen, berechnet werden muß um dann auf die eigentlichen Haswerte zu kommen. Die Differenz wäre dann das Salt.

Vorraussetzung ist natürlich, daß es wirklich fix ist und für alle drei Dateien das selbe Salt ist.