DEC 5.2 String hashen?

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

[a.def]

Zitat:

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

Ok. Zeugenvernehmung beendet. Urteil gesprochen: Zacherl hat das Zepter und kommt eh um alles rum

[himitsu]

Die wichtigen Teile der EXE sind in den RAM gemappt, also kann man das auch im RAM hashen, anstatt die Datei.
Nur muß man hier erstmal alle Teile finden, da erstens die PE-Sektionen einzeln geladen werden, die Reallocationstabellen übershrieben werden und auch überall die Sprung-/Speicheradressen werden vom Windows gepatcht, wenn das Image im RAM verschoben wurde.

[a.def]

Klingt kompliziert und resultiert bestimmt wieder in keinerlei Mehrwert. Denn CreateFile muss man ja nicht suchen denke ich.

[a.def]

Eine Frage hätte ich noch. Ich habe gerade mal beobachtet wie die "E/A Bytes (Lesen)" im Taskmanager aussieht nachdem ich mein Testprogramm starten.
Mit meinem aktuellen Code und einem <Stream>.LoadFromFile() geht der o.g. Wert direkt in die Höhe. Ich würde mal sagen dort steht dann Programmgröße + 200KB.

Wenn ich folgenden Code verwende, dann passiert das nicht. Woran liegt das?

Delphi-Quellcode:

 aFileStream := TFileStream.Create(ParamStr(0), fmOpenRead or fmShareDenyWrite);
 try
  // Get hash from stream end
  SetLength(s, 32 * SizeOf(Byte));
  aFileStream.Position := aFileStream.Size - Length(s);
  aFileStream.Read(s[1], Length(s));

  ShowMessage(s);
 finally
  aFileStream.Free;
 end;

Wo ist also der Unterschied was den Wert "E/A Bytes (Lesen)" angeht zwischen den Zeilen unten?

Delphi-Quellcode:

// Verursaacht hohe (Programmgröße + ~100KB) "E/A Bytes (Lesen)" im Taskmanager
aByteStream := TBytesStream.Create;
aByteStream.LoadFromFile(ParamStr(0));

// Verursacht dieses Problem nicht
aFileStream := TFileStream.Create(ParamStr(0), fmOpenRead or fmShareDenyWrite);

Und: gibt es eine Lösung TBytesStream zu verwenden -ohne- dieses Problem im TaskManager? (TStringStream verursacht diese Anzeige übrigens auch)