DEC 5.2 String hashen?

[a.def]

Ich habe mir gerade nach Jahren noch einmal die DEC-Units angeguckt die ich in einer alten Spielerei gefunden habe.
Dort wird der Hash einer Datei mit CalcFile berechnet.

Gab es nicht auch irgendwann mal die Möglichkeit einen den Hash eines Strings zu berechnen oder irre ich mich?

[TiGü]

Gab es bestimmt, aber für XE8 kannst du auch das hier nehmen:
http://docwiki.embarcadero.com/Libra...g.TNetEncoding

[a.def]

Ich habe gerade durchs Herumstöbern noch etwas gefunden:
System.Hash.THashMD5 (und andere). Sehr viel einfacher und in einer Zeile erledigt!

Delphi-Quellcode:

s := System.Hash.THashBobJenkins.GetHashString('1234567890123456');

Da steht auch ein Hash drin namens BobJenkins. Der Wikipedia-Artikel hilft mir nicht wirklich. Ist der sicher und kann nicht zurück-gerechnet werden?

[TiGü]

Richtig, du wolltest ja hashen, ich war gedanklich woanders.

Möchtest du was hashen oder etwas verschlüsseln?

[a.def]

Eher hashen. Den Originalinhalt brauche ich danach nicht mehr.
Dabei stellt sich mir die Frage: MD5, SHA-XYZ oder BobJenkins. Oder etwas ganz anderes vielleicht.

[nahpets]

Was hast Du denn vor?

EXE gegen Manipulation per HEX-Editor ... schützen?

Da sollte MD5 für 'nen Selbsttest ausreichen.

[a.def]

Im Prinzip ja. Aber auch andere Spielereien. Ich stelle mir grundsätzlich nur die Frage welchen Hash man benutzen könnte ohne ihm direkt anzusehen welcher Algorithmus es ist.

[Michael II]

Hallo a.def

du schreibst

Zitat:

Ist der sicher und kann nicht zurück-gerechnet werden?

Ich kann nicht abschätzen, was du einerseits mit "sicher" und andererseits mit "zurück gerechnet" meinst.

Nur soviel:
MD5 erzeugt zu einer beliebigen Zeichenkette einen 128 Bit Wert.

Die Definitionsmenge ist also unendlich gross, die Wertemenge aber umfasst lediglich 2^128 Elemente.

2^128 ist zwar auch sehr gross, aber eben nicht unendlich. MD5 bildet also eine unendlich grosse Menge auf eine endliche Menge ab. D.h. die Funktion ist zwangsläufig nicht injektiv/eineindeutig. Oder etwas anders ausgedrückt: Es liegt in der Natur dieser Funktion [generell von Hash Funktionen], dass mehrere Zeichenketten auf das gleiche Element (den gleichen Hash Wert) abgebildet werden.

Wenn zwei Zeichenketten auf den gleichen Wert abgebildet werden, dann nennt man dies im Zusammenhang mit Hash Funktionen eine "Kollision".



Wenn du also mit "sicher" meinst "Gibt es zu einem Hashwert w ganz sicher nur eine einzige Zeichenkette z für welche md5(z)=w gilt?", dann lautet die Antwort NEIN. Wie oben beschrieben kann md5 gar nicht injektiv sein. Es kann also gut sein, dass noch weitere Zeichenketten z1,... durch md5 ebenfalls auf w abgebildet werden.

Du fragst nach dem Zurückrechnen. Auch hier lautet die Antwort NEIN. [Wenn dem so wäre, dann wären alle bisherigen Kompressionsprogramme auf dem Markt Unsinn (sie sind es natürlich nicht); denn dann könnte zum Beispiel WinZip jedes Dokument dieser Welt in 2^128Bit speichern. Wir haben aber mit den Überlegungen oben gezeigt, dass dem nicht sein kann.]
Ein einfaches Beispiel dazu, welches dir zeigt, dass Zurückrechnen niemals funktionieren kann: Stell dir vor, du ermittelst für die Zahlen von 1 bis 2^128+1 [egal, ob sie binär vorliegen oder als Zeichenkette] die jeweiligen md5 Werte. Du hast dann 2^128+1 Elemente, aber wie du weisst höchstens 2^128 Funktionswerte. D.h. es muss mindestens 2 Zahlen in 1 bis 2^128+1 geben, welche durch md5 dem gleichen Wert zugeordnet werden. => Zurückrechnen geht nicht.

Injektivität/Eineindeutigkeit:
https://de.wikipedia.org/wiki/Injektivit%C3%A4t

Kollisionen bei md5:
https://de.wikipedia.org/wiki/Messag...st_Algorithm_5

[nahpets]

Die Antwort ist doch ganz einfach: Ein eigener.

Erfüllt zwei Bedingungen:

Es ist ein (lehrreiche) Spielerei.
Kein anderer kann ihn erkennen.

@Michael II
Klasse Erklärung :thumb:

[a.def]

Die Erklärung ist echt der Wahnsinn das stimmt.
Ein eigener Hash? Klingt lustig, würde ich aber niemals hinbekommen :P

Dumme Frage:
ist eine Hash-Funktion nicht anderes als ein wildes herumschupsen von Zeichen?

[himitsu]

BobJenkins ist klein (32 Bit, ähnlich CRC32) und schnell.

MD5 ist größer (128 Bit) und langsamer, aber dafür eben auch "genauer".

SHA1 = 512 Bit


Kommt drauf an, was man erreichen will, wie sehr sich der Hash dann bei "kleineren" Änderungen ändert, wie Manupulationssicher es sein soll und wie schnell es gehn soll.

z.B. XOR, da ändert man zwei Mal das selbe Bit in verschiedenen Bytes und dennoch bleibt der Hash unverändert.
$F8 xor $8F = $77
$E8 xor $9F = $77
$8F xor $F8 = $77

[a.def]

Heißt also je genauer, desto weniger Kollisionen UND desto eher ändert sich der Hash bei Änderungen des Inputs?

Demnach ist XOR also sehr ungenau?

[himitsu]

Jupp.

im gegensatz zu MD5/SHA1 bringen kleine Eingangsänderungen eine große Ausgangsänderung.
Daher ist es schwerer eine "Kollision" zu erreichen.
1 Bit im Input ändern, ändert nahezu alle Bits im Ausgang.

Aber bei XOR ändert es eben nur dieses eine Bit und man kann das mit einem anderen Bit wieder zurückändern.
Da hier auch alle bytes gleich behandelt werden, ist es da auch egal in welchem Byte man das macht.



PS: Kreuzsummen kannst du als Hash-Beispiel missbrauchen.
Einfach alle Bytes ordinal addieren und dann dividieren.
(1 + 3 + 5 + 79 + 19 + 36) mod 16 = ein Hash mit 4 Bit
Wenn ich dir jetzt den Hash 15 gebe, dann hast du aber keine Chance das wieder auf die Ursprungszahlen zurückzurechnen.
Es könnte ja auch
(1 + 3 + 6 + 78 + 19 + 36)
oder
(1 + 3 + 5 + 78 + 19 + 36 + 1)
oder sonstwas sein.



Wie schon erwähnt, gibt es aber immer mehrere Inputs, die den selben Outpout haben.
Somit gibt es bei jedem Hash auch eine "alternative" Lösung.
Jemand hasht dein Passwort, ich erfahre den Hash, rechne zurück oder nutze z.b. eine vorberechnete RainbowTables und besorg mir einfach ein anderes Passwort, was passt.
Es könnte sogar dein eigenes Passort sein, aber das wäre sehr unwahscheinlich und wenn doch, dann wüsste ich es eh nicht, ob es wirklich Deines ist.

[nahpets]

Zitat:

Zitat von a.def (Beitrag 1369825)

Die Erklärung ist echt der Wahnsinn das stimmt.
Ein eigener Hash? Klingt lustig, würde ich aber niemals hinbekommen :P

Warum nicht?

Delphi-Quellcode:

function KomischerHash(s : String; iHashLen : Integer) : String;
var
   i : Cardinal;
   k : Integer;
begin
  i := 0;
  for k := 1 to Length(s) do begin
    i := i + Ord(s[k]);
    if i > MaxLongInt then i := i mod MaxLongInt;
  end;
  Result := '';
  s := IntToStr(i);
  for k := 1 to Length(s) do Result := Result + IntToHex(Ord(s[k]),2);
  while Length(Result) < iHashLen do Result := Result + ReverseString(Result);
  Result := Copy(Result,1,iHashLen);
end;

Statt 'nem String kann man auch 'nen Stream nehmen und den byteweise durchgehen. (Wäre für 'ne EXE sicherlich sinnvoller.)
Eigentlich ist nur Phantasie gefordert.
Und unterschiedliche Eingaben sollten (wenn möglich) zu unterschiedlichen Ergebnissen führen. (Der Hash sollte nicht immer 42 sein ;-))
Vom Ergebnis muss / darf kein Rückschluss auf die Eingabe möglich sein.
Und die Ergebnisse müssen reproduzierbar sein.

Betrachte doch einfach mal diverse Prüfziffern (ISBN, Personalausweisnummer, IBAN ...)
Mehrere dieser "Zeichenfolgen" haben die gleiche Prüfziffer. Aus der Prüfziffer kann man aber nicht auf die "Zeichenfolge" zurückschließen.
Aber wenn Du den Algorithmus kennst, kannst Du jederzeit die Prüfziffer neu berechnen und bei fehlender Übereinstimmung auf eine Manipulation der "Zeichenfolge" schließen.

[Aviator]

Zitat:

Zitat von Michael II (Beitrag 1369816)

[...] (alles :))

:thumb: :thumb: :thumb:

[a.def]

Ich guck mir das später mal genauer an. Das mit TBytes verstehe ich noch nicht genau. Würde super gerne alles auf TBytes umstellen aber naja.
Internet sagt dazu

Delphi-Quellcode:

bytes := TEncoding.UTF8.GetBytes(str);

und

Delphi-Quellcode:

str := TEncoding.UTF8.GetString(bytes);

aber das funktioniert nicht wie gewollt.

[himitsu]

Zitat:

Delphi-Quellcode:

i := i + Ord(s[k]);

Die größeren Hashs machen eher etwa sowas, aber vom Prinzip her ändert sich dabei nichts.

Delphi-Quellcode:

i := i xor (Ord(s[k]) * 12145612) mod 456413);

oder

Delphi-Quellcode:

i := (Ord(s[k]) * 12145612 + i) mod 456413);

ABER: string
Man sollte immer einen "definierten" Input verwenden.
Hier würde ich UTF-8 oder Unicode empfehlen (notfalls auch ANSI, aber besser zukunftsicher, als oldtyle).
Denn solange nur ASCII in den String rein kommt, ändert sich nichts, aber wenn ab Delphi 2009 der "String" ein UnicodeString und kein AnsiString mehr ist, dann ist das Erbebnis der Berechnungen schnell mal ein Anderes. :stupid:
Und auch bei älteren Delphis sieht es in einem deutschen Windows anders aus, als in einem russischen Windows. (andere CodePages)

[nahpets]

Sagen wir mal so:

Ein String als Eingabe für 'nen Hash eher suboptimal.

Byteweise durch 'nen Stream oder ein ByteArray sollte hier sinnvoller sein.

Und es dürfen natürlich keine (wie auch immer gearteten) Abhängigkeiten zu irgendwelchen Systemeinstellungen oder sonstige Konfigurationen bestehen.

Sprich: Es muss immer ein reproduzierbares Ergebnis rauskommen.

Egal auf welchem Rechner, egal unter welchem Betriebssystem ...

[p80286]

Wer bildet den über char einen Hash, das ist doch "stille Post"

Gruß
K-H

[a.def]

---

[nahpets]

Ein Hash ist doch keine Zeichenfolge. Wenn das hier nicht angezeigt werden kann, ist das vollkommen normal.

Ein MD5-Hash ist ein 16 Byte großer Binärwert. Jedes dieser 16 Bytes kann einen Wert von 0 bis 255 annehmen. Die "anzeigbaren Zeichen" sind nur 'ne Teilmenge davon.

Wenn Du den Hash unbedingt anzeigen willst, dann wandle doch diesen Wert in 'ne Zeichenfolge um.

[a.def]

Mein Problem besteht darin, dass ich ja weg von den Strings will in TBytes. Aber ich weiß nicht wie man
a) einen String in TBytes speichert
und
b) diese TBytes dann korrekt über einen Stream abspeichert

[Michael II]

Zitat:

Heißt also je genauer, desto weniger Kollisionen UND desto eher ändert sich der Hash bei Änderungen des Inputs?

Beispiel: 1Bit Hash
Wenn deine Wertemenge 2 Elemente enthält, dann werden alle Elemente deiner Definitionsmenge auf 0 oder 1 abgebildet. Du kannst also deine Definitionsmenge in "zwei Pakete" unterteilen. Wie du die Unterteilung (d.h. deine Hash Funktion) definierst ist abgängig davon, was deine Hash Funktion tun soll.

Beispiel: Wenn h alle Zeichenketten mit dem Wort Delphi erkennen soll, dann reicht eine 1Bit Funktion vollauf. Jeder Zeichenkette, welche Delphi enthält ordnet h die 1 zu, jeder anderen Kette 0 (oder umgekehrt).
Wenn wir davon ausgehen, dass du deiner Funktion h alle Texte dieser Welt füttern willst, dann enthalten die meisten Texte das Wort Delphi nicht. Deine Funktion ist aber für deinen Zweck absolut genau: Du erkennst alle Texte mit dem Wort Delphi.
Du nimmst ohne Einschränkung in Kauf, dass viel mehr Elemente auf 0 als auf die 1 abgebildet werden. D.h. du hast, wenn du zwei zufällige Texte nimmst mit sehr grosser Wahrscheinlichkeit (ungefähr 1) eine Kollision zu erwarten.

Bei anderen Aufgaben bist du eher daran interessiert, die Kollisionswahrscheinlichkeit zu minimieren. (Sortieren, Komprimieren)


Grössere Wertemenge
Wenn du die Wertemenge grösser wählst, dann kannst du natürlich die Definitionsmenge in mehr Pakete unterteilen.

Beispiel:
Eine Hash Funktion h mit einer Wertemenge mit n Elementen erlaubt es dir, deine Definitionsmenge in n Pakte zu untereilen. Je grösser du deine Wertemenge wählst, desto mehr Pakete schnürst du.

Beispiel:
In 32Bits kannst du 2^32 Werte speichern und damit deine Definitionsmenge in 2^32 Pakete unterteilen.


Deine Hash Funktion soll deiner EXE einen Wert zuordnen.

Du musst also eine Hash Funktion wählen
- mit möglichst grosser Wertemenge
- (dieser Teil ist schwierig, wenn du's selbst tun willst), welche EXEs mit ähnlicher Zeichenkette (du bist ja interessiert an Änderungen deines Programms) auf voneinander verschiedene Werte abbildet. [Es kann dir egal sein, ob Word und dein Programm durch h im gleichen Topf landen.]

Es ist eine Riesenaufgabe, solche Hash Funktionen zu definieren. Nimm besser eine erprobte mit grosser Wertemenge.

[a.def]

Jetzt noch einmal für ganz dumme (für mich).
ich lade eine Datei in einen Stream und den Inhalt ändere ich in MD5 oder sonst was.

Delphi-Quellcode:

aFileStream.Position := 0;
SetLength(Bytes, aFileStream.Size);
aFileStream.Read(Bytes[0], Length(Bytes));

Bytes := System.hash.THashMD5.GetHashBytes(TEncoding.ANSI.GetString(Bytes));

aFileStream.Position := aFileStream.Size;
aFileStream.Write(Bytes[0], Length(Bytes));

Wenn ich mir

Delphi-Quellcode:

TEncoding.ANSI.GetString(Bytes)

über Showmessage anzeigen lasse, sehe ich den Dateiinhalt korrekt dargestellt.
Schreibe ich Bytes dann mit Write in den Stream/die Datei, kommt nur Salat in der Datei an.

Bitte sagt mir, dass ich mich auf dem richtigen Weg befinde :pale:

Oder ist das eher so vorgesehen?

Delphi-Quellcode:

aFileStream.Position := 0;
SetLength(Bytes, aFileStream.Size);
aFileStream.Read(Bytes[0], Length(Bytes));

s := System.hash.THashMD5.GetHashString(TEncoding.ANSI.GetString(Bytes));

aFileStream.Position := aFileStream.Size;
aFileStream.Write(s[1], Length(s) * SizeOf(Byte));

[p80286]

Zitat:

Zitat von a.def (Beitrag 1369868)

Mein Problem besteht darin, dass ich ja weg von den Strings will in TBytes. Aber ich weiß nicht wie man
a) einen String in TBytes speichert
und
b) diese TBytes dann korrekt über einen Stream abspeichert

??
Meine naheliegende Lösung wäre

Delphi-Quellcode:

mystream.write(MyString[1],length(mystring)*sizeof(char));

nichts mit TBytes etc. Wenn der String schon vorliegt.
Ansonsten eben ein Array mit TBytes definieren und dann

Delphi-Quellcode:

mystream.write(MyBytes[0],length(myBytes));

Gruß
K-H

Edith:

Delphi-Quellcode:

Bytes := System.hash.THashMD5.GetHashBytes([B]TEncoding.ANSI.GetString[/B](Bytes));

Wofür soll das gut sein?
Wenn du einen Hash erstellst, dann ist das eine "aufgeblasene Quersumme" egal ob Du Goethes Faust oder die Bibel oder die Geschichte der 0 oder meine Kontostände hineingibst, es kommt immer 4711,42 oder 007 heraus.
der Hash von "Faust" ist nicht "Gretchen"!!
(gut kann passieren aber ist unwahrscheinlich)
pps
und für Quersummen benötigt man numerische Werte, keine Zeichen!

[Michael II]

Zitat:

Mein Problem besteht darin, dass ich ja weg von den Strings will in TBytes. Aber ich weiß nicht wie man
a) einen String in TBytes speichert
und
b) diese TBytes dann korrekt über einen Stream abspeichert

Wenn du deine Daten in einem Stream benötigst, dann lade doch dein File direkt dort rein.
Sowohl TMemoryStream wie TFileStream kennen eine Methode LoadFromFile.

[nahpets]

Im Showmessage zeigst Du aber nicht die Binärweert des Hashes an, sondern seine Übersetzung in eine anzeigbare Form.
Und wenn Du die in der DAtei haben willst, dann musst Du auch die in die Datei schreiben.

Hast Du sowas wie TotalCommander?

Dann nimm den mal. Gehe zur Datei mit dem Hash.
Taste F3 zur Anzeige.
Taste 3 zur Hexadezimalanzeige.
Taste Ende, um ans Ende der Datei zu gehen.

Dort siehst Du dann rechts den Binärwert byteweise. Im mittleren Teil die 16 Hexadezimalwerte dazu.

Und ja, nichtanzeigbare Werte (von Dir als Salat bezeichnet) sind vollkommen normal und in Ordnung.

Ein MD5-Hash ist ein Binärwert und keine (unverarbeitet) sinnvoll anzeigbare Zeichenfolge. Es ist kein String.

Der MD5-Hash des Programmes, an dem ich gerade arbeite ist zur Zeit:

Code:

-š³úc;o6¦¥,1<4;

(Das vorletzte Zeichen kann hier nicht dargestellt werden.)

Hexadezimal:

Code:

2D 9A B3 FA 63 3B 6F 36 A6 A5 2C 31 3C 34 06 3B

[himitsu]

BinToHex

TGUID hat zufällig gleich viele Bytes wie ein MD5 ... ein Schelm, wer das einfach mal castet.

[a.def]

Ok das bedeutet also, dass man, wenn man einen Hash erzeugen möchte, eben auch nicht mit TBytes arbeiten kann.
Ich dachte nur ich ändere alles auf TBytes um, da im anderen Thread ja empfohlen wurde von String weg zu TBytes zu gehen.

[nahpets]

String ist aber auch nicht sinnvoll.

Wenn man 'nen Hash auf 'ne Exe machen will, geht man sie bytewesie durch.

TFileStream oder TMemoryStream dürften hier eher die Mittel der Wahl sein.

Unter Delphi 7 nutze ich diese Unit: https://sourceforge.net/p/lazarus-cc...hes/dcpmd5.pas

Das geht dann ungefähr so:

Delphi-Quellcode:

function  TfmMain.GetMD5(st : TMemoryStream) : String;
var
  Digest        : array[0..15] of byte;
  i             : Integer;
  iPos          : Integer;
  md5           : TDCP_md5;
begin
  md5         := TDCP_md5.Create(Self);
  iPos        := st.Position;
  st.Position := 0;
  md5.Init;
  md5.UpdateStream(st,st.Size);
  md5.Final(Digest);
  Result := '';
  for i  := 0 to 15 do Result := Result + IntToHex(Digest[i],2);
  st.Position := iPos;
  md5.Free;
end;

MD5 an 'ne Datei anhängen:

Delphi-Quellcode:

var
  Digest        : array[0..15] of byte;
  i             : Integer;
  iPos          : Integer;
  md5           : TDCP_md5;
begin
  md5 := TDCP_md5.Create(Self);
  sf := tFileStream.Create(ParamStr(0),fmOpenReadWrite);
  md5.Init;
  md5.UpdateStream(sf,sf.Size);
  md5.Final(Digest);
  sf.Position := sf.Size;
  for i := 0 to 15 do sf.Write(Digest[i],1);
  sf.Free;
  md5.Free;
end;

In neueren Delphis gibt es dashier: http://docwiki.embarcadero.com/Libra...hBytesFromFile

Ich rate jetzt mal, es könnte so ein Einzeiler sein:

Delphi-Quellcode:

ShowMessage(TEncoding.ANSI.GetString(System.Hash.THashMD5.GetHashBytesFromFile(ParamStr(0)));

Das Ergebnis davon an 'ne Datei zu hängen, dürften dann kein Problem mehr sein.

[a.def]

Mh ich habe das so realisiert (hoffe ihr haut mich nicht)
--- siehe Anhang Beitrag 34 ---

Ich habe ein kleines Programm welches nur den Code enthält um den Hash an eine Datei zu hängen. Alle anderen Dateien enthalten nur den Code um den Hash auszulesen.
Nachdem ich alles kompiliert habe, ziehe ich einfach meine Exe-Dateien in dieses kleine Tool, klicke den Button und jede Exe bekommt einen Hash verpasst.

[nahpets]

Das kann man noch ausbauen:

Baue einen AfterCompile-Experten.

Der hängt nach der erfolgreichen Kompilierung den Hash direkt an die Exe, dann sparst Du die die Nutzung des Tools und kannst auch nicht mal vergessen den Hash an 'ne Exe zu hängen.

Die von Dir geschrieben Funktionen kannst Du auch in 'nem Experten verwenden.

[BrightAngel]

Kurzer Zwischeneinschub: Wenn dein Ziel wirklich die kryptographische Sicherheit ist, dann würde ich dir nicht empfehlen diese selbst zu basteln. Es ist wirklich "mal schön" sowas zu auszuprobieren und daran herum zu probieren, aber im Allgemeinen ist das nicht wirtschaftlich, da es wesentlich einfachere Lösungen gibt. Eine Hashfunktion so zu konstruieren, sodass sie kryptographisch nicht so einfach angreifbar ist, ist schwer! Es muss "hinreichend" schwer sein Kollisionen künstlich erzeugen zu können. Die Funktion muss zusätzlich die "normalen" Vorteile erfüllen: möglichst breit "streuen", Berechenbarkeitsaufwand "vorhersehbar" deterministisch, ...
Fertige Primitive stehen auch stärker im öffentlichen Fokus, sodass Schwächen auch öffentlich im Interesse stehen und man davon mitbekommt. Die Funktionen sind so komplex, dass man sich auch gegen verdeckte Manipulation schützen kann.

Eine Idee als Lösung ist zum Beispiel das Kaskadieren verschiedener Hashfunktionen, das heißt das hintereinanderausführen verschiedener oder gleicher Hashfunktionen, die vielleicht dazwischen noch mit Klartext konkateniert werden, oder oder...

Gruß :thumb:,
Brighty

[a.def]

Für alle die es interessiert, hier ist meine fertige Selftest-Unit.
Sie ist Writer und Reader in einem.
Aufgerufen wird in der DPR-Datei mit

Delphi-Quellcode:

THashFunctions.doSelfTest(<Dateiname>);

Verbesserungsvorschläge gerne erwünscht! Mit dem Onlinestellen dieses Codes möchte ich euch gerne zeigen, dass ich natürlich auch versuche Dinge umzusetzen, auch wenn ich mich super-doof anstelle bei 9 von 10 Gelegenheiten.

Delphi-Quellcode:

// Selbsttest ausführen, vorzugsweise am Anfang der DPR-Datei (?)
THashFunctions.doSelfTest(<Dateiname>);

// Einer Datei einen Hash unterjubeln
THashFunctions.setFileContentHash(<Dateiname>);

// Hash einer Datei manuell auslesen (warum auch immer)
THashFunctions.getFileAddedHash(<Dateiname>);

Zitat:

Wenn dein Ziel wirklich die kryptographische Sicherheit ist, dann würde ich dir nicht empfehlen diese selbst zu basteln. Es ist wirklich "mal schön" sowas zu auszuprobieren und daran herum zu probieren, aber im Allgemeinen ist das nicht wirtschaftlich, da es wesentlich einfachere Lösungen gibt.

Ist eher eine Spielerei, welche ich trotzdem anwenden werde. Ich biete Freeware an und verdiene kein Geld damit. Ob ich an einer Lösung 1 Stunde oder 1 Tag sitze, ist mir im Prinzip egal.

[Michael II]

Hallo a.def

nur kurz: Am Ende des Files fällt dein md5Hash auf wie ein bunter Hund.

In einem weiteren Schritt wirst du nun den Hash Code direkt irgendwo in deine Programm Exe schreiben ;-).

Eine Frage nebenbei: Wie vertreibst du deine Freeware? Wenn via Download von einer Webseite, dann musst du diese doch sicher irgendwann auch digital signieren - oder hast du derart hohe Downloadzahlen, dass Edge und Co den Download auch so zulassen?


Gruss
M

[a.def]

Zitat:

nur kurz: Am Ende des Files fällt dein md5Hash auf wie ein bunter Hund.

Ja, leider. Ich hätte sonst keine Idee wo man ihn verstecken könnte.

Zitat:

In einem weiteren Schritt wirst du nun den Hash Code direkt irgendwo in deine Programm Exe schreiben.

Ok das verstehe ich nicht. Was genau meinst du?
Wenn glaube zu verstehen was du meinst, dann schreibe ich dir das jetzt mal per PN :P

Zitat:

Wenn via Download von einer Webseite, dann musst du diese doch sicher irgendwann auch digital signieren - oder hast du derart hohe Downloadzahlen, dass Edge und Co den Download auch so zulassen?

Hatte bisher keinelei Probleme. VirusTotal hat bei meiner Exe auch nicht gemeckert (Detection ratio: 0 / 61).

Digital signieren wäre echt schön, ist mir aber zu teuer. Muss ich dafür nicht sogar meinen Sourcecode preisgeben?
Was würde ein digitales Zertifikat denn im günstigsten Falle kosten? Und wäre das dann auch alles seriös?

Was die Downloadzahlen angeht. Wenn ich ein Update veröffentliche dann schnellt mein Traffic mal gerne auf 10GB und mehr pro Monat.

[Michael II]

Dann hast du sicher riesige Downloadzahlen und deine User sehen nie "..diese Datei wird selten...".."...könnte schaden...trotzdem?"


Zur Zertifikatsfrage:
Du musst den Code selbstverständlich nicht preisgeben. Du signierst deine exe-Files auf deiner Kiste.

Die Preise für Zertifikate sind ziemlich verschieden. Ich habe meines von einem Reseller von comodo. Das Zertifikat selbst wird in meinem Fall (wie wenn ich es von comodo gekauft hätte) direkt von comodo ausgestellt.

Ich musste nach meinem Antrag eine Stromrechnung oder eine Telefonrechnung und eine Kreditkartenrechnung via eMail oder Fax einreichen. Auf diesen Rechnungen musste natürlich meine Adresse [die gleiche wie beim Zertifikatsantrag] stehen. Dann ging's ab zum Notar. Dieser beglaubigte meinen Ausweis (in CH Identitätskarte). Das beglaubigte Dokument musste ich danach irgendwo in die USA senden. Bei der Beglaubigung empfehle ich dir den Notar zu bitten, dass er es genau so macht wie vom Aussteller verlangt wird, sonst drehst du eventuell eine "Ehrenrunde Notar II" [Beglaubigungen werden nicht überall auf dieser Welt gleich ausgestellt. Eigentlich sollte die Beglaubigung natürlich so ausgeführt werden wie es bei dir oder mir üblich ist, aber... ;-)].

Wenn du als Firma eingetragen bist, dann sind gewisse dieser Schritte nicht nötig.

Darauf rief comodo bei mir an und fragte, ob ich ein Zertifikat beantragt hätte - und rief beim Notar an und fragte, ob er meine ID beglaubigt hätte.

Kurz nach diesem Anruf erhielt ich mein Zertifikat.

Falls du eins kaufst, dann entscheide dich für eines für mehrere Jahre, weil du je nach Aussteller beim nächsten Mal wieder durch die gleiche Mühle durch musst. [In der CH sind die Notarkosten kantonal geregelt - im Kanton Bern sind sie hoch - ich bezahlte mehr für die Beglaubigung als ich für 1 Jahr Zertifikat bezahlt hätte...]

Dort wo ich meins kaufe, kosten vier Jahre US$268. Du hast eventuell in Deutschland günstigere Reseller.

[a.def]

Ok das ist mir dann doch etwas zu teuer und für eine Freeware absolut nicht nötig.
Zur Edge-Meldung. Ich habe gerade meine Datei, die schon seit Dezember auf dem Server liegt, selber runtergeladen und diese Meldung nicht erhalten. Es war eine Exe-Datei.

Was den Hash angeht. Wo könnte man ihn denn sonst verstecken? Denn sobald ich den Inhalt meiner Exe mit notepad++ ändere, und auch wenn es nur 1 Byte ist, ist die Exe wohl "kaputt".

[p80286]

Zitat:

Zitat von a.def (Beitrag 1369933)

Ok das ist mir dann doch etwas zu teuer und für eine Freeware absolut nicht nötig.
Zur Edge-Meldung. Ich habe gerade meine Datei, die schon seit Dezember auf dem Server liegt, selber runtergeladen und diese Meldung nicht erhalten. Es war eine Exe-Datei.

Was den Hash angeht. Wo könnte man ihn denn sonst verstecken? Denn sobald ich den Inhalt meiner Exe mit notepad++ ändere, und auch wenn es nur 1 Byte ist, ist die Exe wohl "kaputt".

So ist das vgl.


Was u.U eine Möglichkeit wäre, Platz für den Hash und sein "Spiegelbild" vorbelegen, damit die Prüfsummenprüfung nicht zuschlägt.

Gruß
K-H

[nahpets]

Eigentlich "gaaaaanz" einfach ;-)

Definiere eine Stringkonstante im Quelltext.

Delphi-Quellcode:

csMD5 = '@@@@HashwertHashwertHashwertHashwert@@@@'

Dann berechnest Du den Hashwert unter Auslassung des Bereiches in der Exe, der von der Konstanten belegt wird. (Das zwischen den beiden @@@@.)

Den Wert der Konstanten ersetzt Du anschließend durch den Hashwert.

Beim Prüfen berechnest Du den Hashwert unter Auslassung des Bereiches zwischen den @@@@ und vergleichst ihn mit dem Wert zwischen den @@@@.

Soweit, so theoretisch.

Ich bleib lieber bei der Checksumme am Ende der Exe. Wer die Checksumme am Ende synchron zur Exe so manipulieren kann, dass Deine Prüfung nicht fehlschlägt, ändert sie auch irgendwo mitten in der Exe.

Wenn die Checksumme am Ende steht, so steht da ja noch nicht drin, über welchen Bereich der Exe sie gemacht wurde. Muss ja nicht die ganze Exe sein, könnten ja auch nur die ersten X Byte sein. Oder MD5-Checksumme einer MD5-Checksumme oder die Checksumme wird vorm Speichern noch mit irgend 'nem Wert gexodert ...

Oder anders:

Man kann's auch übertreiben.
Konsequent zuende gedacht kommt man hier dann zum klassischen Wettrüsten.

Code:

While Universum besteht do begin
  Krieg ich's noch sicherer?
  Die Sicherung kann ich knacken!
end.