DEC 5.2 String hashen?

[Fritzew]

Zitat:

Zitat von Michael II (Beitrag 1370088)

Also Zacherl hat voll Recht.

Wenn du die Abfrage nicht verschleierst, dann ist man durch, wenn man wie hier die Bedingung "stimmt der Hashwert noch" einfach aushebelt.

Als kleine Knobelei könntest du ja deine Abfrage etwas verstecken und Zacherl dann mal deine exe übergeben ;-).

... und die fünf Minuten stoppen.

[ Und dein Programm sollte dann nicht einfach ausgeben "Ich wurde gehackt" sondern zum Beispiel wenn es ein Spiel ist - einfach schlechter mitspielen. ]

Wenn ich deine vorherigen Antworten so anschaue:
Du lehnst Dich aber sehr weit aus dem Fenster, eine Exe Datei in einem Stringstream zu verarbeiten, grenzt meiner Meinung nach schon an masochismus.....

[nahpets]

Zitat:

Zitat von Fritzew (Beitrag 1370098)

Wenn ich deine vorherigen Antworten so anschaue:
Du lehnst Dich aber sehr weit aus dem Fenster, eine Exe Datei in einem Stringstream zu verarbeiten, grenzt meiner Meinung nach schon an masochismus.....

Mindestens ...

Filestream wäre da meine Wahl, aber binäre Daten als Zeichenfolge, eher nicht.

[Fritzew]

Zitat:

Filestream wäre da meine Wahl, aber binäre Daten als Zeichenfolge, eher nicht.

Danke.. Dachte schon ich bin allein :-)
ok nur auf die schnelle zum erzeugen einer Hash:

Delphi-Quellcode:

procedure tFileHasher.SchreibeHashWertAnFileEnde(filename: string);
const
  cChunkSize = 1024 * 1024; // Buffersize 1 MB

var
  f: TFileStream;
  lFileBytes: TBytes;
  lHashBytes: TBytes;
  lHasher: THashMD5;
begin
  f := TFileStream.Create(filename, fmOpenReadWrite);
  try
    setlength(lFileBytes, cChunkSize);
    lHasher.Reset;
    while f.ReadData(lFileBytes, cChunkSize) > 0  do
      lHasher.Update(lFileBytes);


    lHashBytes := lHasher.HashAsBytes;
    f.Seek(0, soFromEnd);
    f.WriteData(lHashBytes, Length(lHashBytes));
  finally
    f.Free;
  end;
end;

[a.def]

Ich bedanke mich für die Hilfe aller Beteiligten.

Ich habe mir jetzt eine schöne Unit zusammengebaut, welche (für mich) keine Wünsche offen lässt was die Funktionalität angeht.
Ach, Moment. Doch. Einen Wunsch äußert die Unit von sich aus. Er lautet in etwa ... "RÄUM MICH AUF!" :stupid:

Ich habe es so einfach gehalten wie möglich (mit eurer Hilfe).

Delphi-Quellcode:

// Selbsttest ausführen
THashFunctions_Selftest.doSelfTest(<Dateiname>);

// Hash einer Datei unterjubeln
THashFunctions_Selftest.doHashAction(<Dateiname>, <Option XY [Hash ans Ende oder mitten drin]>);

[Zacherl]

Zitat:

Zitat von a.def (Beitrag 1370085)

Zitat:

Das ist in den meisten Fällen tatsächlich ein 1-Byte Patch, den selbst Anfänger auf diesem Gebiet innerhalb von ein paar Minuten vornehmen können.

Ich behaupte einfach mal, dass das aus der Luft gegriffen ist.

Du darfst mir deine Testanwendung gerne zukommen lassen, dann setze ich mich morgen mal ran und patche dir die Abfrage raus, ohne den Hash anzufassen (gerne kann ich dir danach auch näher erklären, wie ich es gemacht habe). Das ist wirklich keine Hexerei, glaub mir.

Zitat:

Zitat von a.def (Beitrag 1370085)

Ich mache diese Spielerei aus zwei Gründen:
1) ich bin dumm und will lernen
2) es gibt Webseiten die mein Programm geklaut haben und bieten es nun modifiziert selber an

Erster Grund ist ja vollkommen legitim. Gegen den zweiten Umstand wird deine Spielerei hier absolut gar nicht helfen.

Allgemein kann ich dir zum Thema Anti-Cracking nur sagen, dass dein Programm mit entsprechendem Zeitaufwand wirklich IMMER gecrackt werden kann. Des Weiteren ist es vom Aufwand-/Nutzen Verhältnis her auch immer Blödsinn irgendeine eigene Lösung zu basteln. Nimm fertige Anwendungen wie VMProtect oder Themida, dann wird der Zeitaufwand für jeden 0815 Cracker auf jeden Fall zu hoch (kosten allerdings auch je nach Version eine Kleinigkeit).

[a.def]

Das lohnt sich alles nicht. Ist schließlich Freeware.

Frage: kann man eine simple Abfrage überhaupt "verstecken" oder schleiern oder geht das nicht?

[nahpets]

Habe ja auch mal 'ne MD5-Checksummenprüfung für meine Programme gebaut.
Und früher auch mit UPX gepackt.

Das kann man kombinieren.

Exe erstellen.
Mit UPX packen.
MD5-Checksumme (oder auch beliebige andere) hinten dran hängen.

Zur Prüfung wird ja die EXE-Datei gelesen, die Checksumme ermittelt und mit dem Ende der Datei verglichen.

Die Prüfroutine befindet sich nun aber in dem gepackten "Teil" und wird erst nach dem Entpacken beim Start der eigentlichen Exe ausgeführt.

Frage: Kann man die Prüfung dann auch "mal eben" wegpatchen?


'ne "somaleben"-Änderung der gepackten Exe kann ich mir jedenfalls nicht vorstellen.
Die Änderung müsste dann wohl eher zur Laufzeit im Arbeitsspeicher passieren.

Naja, und wenn man dann bei der Checksummenerstellung und -prüfung nicht einfach die gesammte Datei nimmt oder eine nicht handelsübliche Routine nimmt, kann man bei 'ner gepatchten Datei nicht unbedingt so mal eben eine korrekte Checksumme "hintendranhängen".

Klar, was man mit UPX packt, kann man auch mit UPX entpacken, dann passt aber die Checksumme nicht mehr und die Prüfung muss man dann aushebeln.

Wer will kann also schon dran, nur bis zu welchem Aufwand soll's getrieben werden?

[Michael II]

Zitat:

Danke.. Dachte schon ich bin allein
ok nur auf die schnelle zum erzeugen einer Hash:

Hast natürlich voll Recht Fritz - ein Hash welcher einer Bytefolge Bytes zuordnet muss auch bei Bytes bleiben. :thumb:

Zu deinem Code: Beim Lesen des letzten File Teils, solltest du den Hash nur über die effektiv gelesenen Bytes updaten. [Mit dem momentanen Code hast du cChunkSize - filesize mod cChunkSize Files mit gleichem Wert.]

Nebenbei: Wie jemand hier bereits erwähnt hat: GetHashBytesFromFile( filename ) ist in System.Hash bereits definiert.

[Rollo62]

+1 @Zacherl

Zitat:

Verschleiern

Ich würde also nicht

Delphi-Quellcode:

  if not CheckHashValid then
    Message('Ich wurde gehackt');

schreiben.

Sondern wenigstens

Delphi-Quellcode:

  if not CheckHashValid then
  begin
    Flag1 := False;
    Flag2 := False;
    Flag3 := False;
    ...
    Flagn := False;
  end;

...

//Nach unspezifischem Vorgang, z.B. Timer
if not Flag1 then
  TimedCrash1.Start( Time1 );


//Nach unspezifischem Vorgang, z.B. OnHidDeviceArrival
if not Flag2 then
  TimedCrash2.Start( Time2 );

....

Das hat nur zwei Probleme:

• Darüber grinst Zacherl immer noch, aber aus 5 Minuten werden vielleicht 5h, und er geht vorher in die Mittagspause und hats am Nachmittag vergessen :stupid:
• Deine Kunden kriegen unvermittelte, zufällige Crashes, das gibt u.U. schlechtes Image bei deinen "Usern".
  Ich habe es mal so gemacht das ich die CrashReason irgendwo vorher gespeichert haben, File, Registry.
  Und dann erst nach neuem Start etwas angezeigt habe.

Rollo

[a.def]

Was mir auch direkt aufgefallen ist:

Delphi-Quellcode:

  if not CheckHashValid then
    Message('Ich wurde gehackt');

Bei dieser Ausgabe wäre der Text "Ich wurde gehackt" sehr nah an der Position von CheckHashValid in der Datei gespeichert.
Hast du daher die Flags dazwischen geschrieben und den Timer, damit das weiter auseinander ist?

Den Text der MessageBox auszulagern, wäre auch eine tolle Idee. Dann kann man wenigstens nicht mehr direkt danach suchen.
Schöner wäre natürlich, wenn der Text der MessageBox irgendwie "verschlüsselt" in der Exe liegt und dieser dann entschlüsselt wird (behaupte ich als Laie einfach mal :stupid: )
Oder man könnte die Texte ja in eine Resourcedatei packen, die dann in die Exe eingebunden wird.