DEC 5.2 String hashen?

[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.

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
• 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 )
Oder man könnte die Texte ja in eine Resourcedatei packen, die dann in die Exe eingebunden wird.

[Rollo62]

Exakt, das wäre mein Vorschlag.

Wenn es zeitlich und räumlich nicht so nah ist, und an zig verschiedenen Stellen,
wird es zumindest nicht so leicht zu hacken sein.

Der Hacker braucht ja events um zu checken wann geprüft wird und wann wans entschieden wird.
Ich würde die Prüfung daher niemals direkt bei Start machen.

Lass das Programm doch eine Weile laufen, und überleg dir mittendrin ein paar Scherze, oder speichere erst bei Programmende die neue Situation.

Ist natürlich witzlos wenn die App nach einer Minute Ihren Zweck erfüllt hat, aber für Daueranwendungen
kann man Hacker schon etwas beschäftigen.

Rollo

[a.def]

Zitat:

Lass das Programm doch eine Weile laufen, und überleg dir mittendrin ein paar Scherze, oder speichere erst bei Programmende die neue Situation.

Das ginge bei meinem Programm leider nicht. Es ist zwar eine Anwendung die dauernd läuft, aber sie erledigt zeitkritische Dinge. U.a. direkt bei Programmstart und Programmende.

Bin mit meiner aktuellen Lösung zufrieden. Werde die aber noch weiter ausbauen.

[Zacherl]

Zitat von nahpets:

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

Zitat von nahpets:

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

UPX bietet - wie du ja selbst erwähnst - von Haus aus eine Funktion an, mit der man Dateien wieder entpacken kann. Bietet also auch keinen größeren Schutz. Man patcht nicht den Hash, sondern die Prüfung ansich.

Zitat von nahpets:

Die Änderung müsste dann wohl eher zur Laufzeit im Arbeitsspeicher passieren.

Diese Möglichkeit gibt es natürlich auch noch jederzeit. Entweder per Loader, oder man modifiziert die IAT, um dem Programm eine extra DLL unterzumogeln. Lohnt sich bei Tools, welche auch erst zur Laufzeit (partiell) unpacked werden und so gute Hash-Checks besitzen, dass es vom Zeitaufwand schnell in die Stunden/Tage gehen könnte sie auszubauen.

Zitat von Rollo62:

Wenn es zeitlich und räumlich nicht so nah ist, und an zig verschiedenen Stellen,
wird es zumindest nicht so leicht zu hacken sein.

Das ist in der Tat schonmal eine Stufe aufwändiger - besonders, wenn man eine dynamische Analyse per Debugger vornimmt.

Zitat von Rollo62:

Der Hacker braucht ja events um zu checken wann geprüft wird und wann wans entschieden wird.

Exakt. Wobei viele Leute auch statische Analysen mit IDA vornehmen und dabei nicht auf irgendwelche Events angewiesen sind. Hierfür muss man allerdings in der Regel schon direkt mehr Zeit einplanen, um relevante Codestellen zu finden.

Zitat von a.def:

Aktuell ist meine Unit umfangreich mit ein paar Einstellungsmöglichkeiten und ich brauche nur an einer einzigen Stelle etwas hinschreiben, damit der Selbsttest ausgeführt wird.

Genau das ist aber leider absolut kein Vorteil. Hast du eine inline Funktion, welche du an mehreren Stellen - z.b. wie von Rollo beschrieben beim Auftreten "zufälliger" Events - einsetzt, dann muss ich auch diverse Stellen patchen und kann mir außerdem erstmal nie sicher sein, wirklich alle Vorkommen gefunden zu haben. Nagut, habe ich eine Stelle, kann ich nach der entsprechenden Code-Signatur im ganzen Programm suchen, aber im Optimalfall verwendest du mehrere komplett individuelle Funktionen.

Edit:
Ich habe mal noch ein paar Bilder angehangen, die die Vorgehensweise demonstrieren. Den String zu verschleiern würde in diesem Falle keinen Mehrwert erzeugen, da man stattdessen auch einen Breakpoint auf MessageBoxW setzen könnte. Und selbst komplett ohne MessageBox kann man die Routine finden, welche den hinterlegten Hash aus der Datei ausliest, indem man einen BP auf CreateFileW platziert.

[a.def]

Zitat:

aber im Optimalfall verwendest du mehrere komplett individuelle Funktionen.

Habe ich zum Glück schon. Mein Programm prüft einmal diese Hash-Sache und dann aber noch etwas komplett anderes.

Zitat:

indem man einen BP auf CreateFileW platziert.

Um CreateFileW kommt man vermutlich nicht herum richtig? (Datei anderweitig laden)

Allgemeine Frage an dich nahpets:
wirst du deine Methode weiterhin benutzen und einen Selbsttest durchführen?

[Zacherl]

Zitat von a.def:

Zitat:

indem man einen BP auf CreateFileW platziert.

Um CreateFileW kommt man vermutlich nicht herum richtig? (Datei anderweitig laden)

Würde mir zumindest auf Anhieb jetzt keine Möglichkeit einfallen, die nicht genauso einfach zu erkennen ist.